Differences between revisions 4 and 5
Revision 4 as of 2008-08-02 12:38:57
Size: 35599
Editor: PavelSutyrin
Comment: расшифровано
Revision 5 as of 2008-08-06 14:31:50
Size: 32551
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Администратор сам себя. перебираемся к курсу "Расширенный курс системного администрирования." ##Администратор сам себя. перебираемся к курсу "Расширенный курс системного администрирования."
Line 3: Line 3:
== Репозиторий, ветка, дистрибутив == ##== Репозиторий, ветка, дистрибутив ==
Line 5: Line 5:
Понятно, если человек не очень хорошо умеет управлять своим компьютером даже на уровне своих пользовательских потребностей, то в таком виде бросать человека нельзя. ##Понятно, если человек не очень хорошо умеет управлять своим компьютером даже на уровне своих пользовательских потребностей, то в таком виде бросать человека нельзя.
##К чему эти две фразы? Интернет дома ограничен, аудио прослушать не могу.
Line 9: Line 10:
Чуть ранее был блок, посвященный сообществу, и была такая тема: сообщество вокруг дистрибутива программного продукта, не вокруг одного конкретного свободного ПО, а вокруг дистрибутива, я еще показывал, что аналогия достаточно прямая, есть разделение на ядро разработчиков и пользователей и в случае отдельного ПО, и в случае дистрибутива, во втором случае в роли разработчиков выступают сопровождающие, они же мейнтейнеры, роль разработчика никуда не девается, потому что они обеспечивают всему эту занятию стабильность (если бы мы тратили все ресурсы на поддержку core team и надеяться только на них, и приход был бы равен расходу, то ничем иным, кроме как торговать воздухом, т.е. лицензиями, мы бы не смогли, иначе бы мы просто прогорели. В случае организации бизнеса на основании свободного ПО, у нас такой вот ресурс (средний слой -- разработчики), который выполняет роль бесплатных разработчиков, в нашем проекте участвуют все, кому это интересно и кто может себе помочь в развитии этого проекта. Пользователи у нас -- это такие бесплатные тестеры (опять же, это неправильно сказано, так обычно говорят наши оппоненты: вот у вас есть бесплатные разработчики, которые кое-как все делают, а тестируете вы на пользователях, там есть другая картина, она становится более очевидной, когда мы говорим, что есть информационная связность, и главное -- это не только наличие этих самых людей, но и активное участие в информационном пространстве, тогда пользователи отнюдь не подопытные кролики, а в первую очередь заказчики, получается, что совершенно не понятно, почему разработчики должны работать хуже, чем ядро, они работают иногда даже лучше, просто человек слишком высокий профессионал, чтобы все свое время посвящать нашему проекту, но иногда принимает в нем участи, за что ему большое спасибо.) Чуть ранее был блок, посвященный сообществу, и было сказано о сообществе не вокруг одного конкретной свободной программы, а вокруг дистрибутива. Аналогия достаточно прямая, есть разделение на ядро, разработчиков и пользователей и в том, и в другом случае. В сообществе вокруг дистрибутива в роли разработчиков выступают сопровождающие(мейнтейнеры, от англ. maintainer), роль разработчика остается, потому что они обеспечивают этой структуре стабильность. В случае организации бизнеса на основании свободного ПО, у нас есть ресурс (средний слой -- разработчики), который выполняет роль бесплатных разработчиков, в нашем проекте участвуют все, кому это интересно и кто может себе помочь в развитии этого проекта. Пользователи у нас -- это такие бесплатные тестеры (опять же, это неправильно сказано, так обычно говорят наши оппоненты: вот у вас есть бесплатные разработчики, которые кое-как все делают, и тестируете вы на пользователях. На самом деле картина другая, она становится более очевидной, когда мы говорим, что есть информационная связность, и главное -- это не только наличие этих самых людей, но и активное участие в информационном пространстве. Тогда пользователи уже не подопытные кролики, а в первую очередь заказчики. К тому же, совершенно не понятно, почему разработчики должны работать хуже, чем ядро, они работают иногда даже лучше, например, человек может быть слишком высоким профессионалом, чтобы все свое время посвящать нашему проекту, но иногда принимает в нем участие, за что ему большое спасибо.)
Line 11: Line 12:
В случае дистрибутивов роль core team -- определять стратегическое направление -- куда развивать дистрибутив, и не давать проявляться субъективным факторам как то ленивым разработчикам, ленивым или просто ушедшим на другую деятельность по ключевым направлениями, чтобы конкретное ключевое направление, допустим, веб-браузеры, чтобы веб-браузер был на уровне, и чтобы ядро ОС было достаточно защищено и современное, а то вот если вдруг какой-то сторонний человек, не входящий в core, вообще изредка участвующий в этом сообществе, с ленцой, вдруг получается так, что он занимается ключевой частью дистрибутива, не исключены ошибки: в ядре ОС давно ошибки, а оно все еще висит старое. В случае дистрибутивов роль core team -- определять стратегическое направление, в котором развивать дистрибутив, и не давать проявляться субъективным факторам, например ленивым или просто ушедшим на другую деятельность разработчикам. Необходимо, чтобы и веб-браузер был на уровне, и чтобы ядро ОС было достаточно защищенное и современное, а если какой-то сторонний человек, не входящий в core, и вообще изредка участвующий в этом сообществе, занимается ключевой частью дистрибутива, то может получиться такая ситуация: в ядре ОС давно обнаружены и исправлены ошибки, а в дистрибутиве все еще находится старое.
Line 13: Line 14:
Так вот, по отношению к дистрибутиву у core team сохраняются все те же функции, что и по отношению к обычной свободной программе, а вот что касается понятия разработчика -- оно слегка размывается, т.к. основной ключевой фигурой по отношению к дистрибутиву становится мейнтейнер, он же сопровождающий. Это человек, который имеет некоторую необходимость использовать программный продукт в рамках нашего дистрибутива, и эта необходимость настолько сильная, что он готов сам заниматься сборкой этого продукта, т.е. превращением из исходного кода в бинарный, и адаптацией его под конкретные условия, под дисциплину сборки программных продуктов, принятую в нашем дистрибутиве. Более того. в действительности дистрибутив -- это конечный продукт некоей технологии, которая в качестве базового элемента имеет не дистрибутив, а то что называется хранилище. Так вот, по отношению к дистрибутиву у core team сохраняются все те же функции, что и по отношению к обычной свободной программе, а понятие разработчика слегка размывается, т.к. основной фигурой на этом месте становится мейнтейнер, он же сопровождающий. Это человек, который имеет некоторую необходимость использовать программный продукт в рамках нашего дистрибутива, и эта необходимость настолько сильная, что он готов сам заниматься сборкой этого продукта, т.е. превращением из исходного кода в бинарный, и адаптацией его под конкретные условия, под дисциплину сборки программных продуктов, принятую в нашем дистрибутиве. Более того. в действительности дистрибутив -- это конечный продукт некоей технологии, которая в качестве базового элемента имеет не дистрибутив, а то что называется хранилищем(англ. repository).
Line 17: Line 18:
С точки зрения человека, который вообще не в курсе, хранилище выглядит просто как свалка, набор программных продуктов, адаптированных для работы в конкретном дистрибутиве. Набор достаточно внушительный, в хранилище ALTLinux их порядка 9 тысяч, или больше. Если приглядеться, в хранилище есть несколько дополнительных свойств, которые делают его не просто FTP-сайтом со складом файлов. Во-первых, файлы, которые помещаются в хранилище, помещаются туда этими самыми мейнтейнерами пакетов. С точки зрения человека, не знакомого с этой технологией, хранилище выглядит просто как свалка, набор программных продуктов, адаптированных для работы в конкретном дистрибутиве. Набор достаточно внушительный, в хранилище ALTLinux их порядка 9 тысяч. Если приглядеться, в хранилище есть несколько дополнительных свойств, которые делают его не просто FTP-сайтом со складом файлов. Во-первых, файлы, которые помещаются в хранилище, помещаются туда мейнтейнерами пакетов.
Line 21: Line 22:
Человек, который вдруг решил, что ему необходимо использовать некий программный продукт, который до этого не был адаптирован к некоторому дистрибутиву, он этот продукт скачивает с сайта производителя, собирает их исходников бинарный продукт, и помещает результат работы в это самое хранилище, пользуясь правами члена сообщества. НЕ всякий человек может туда положить пакет, а только тот, который, условно говоря, сдал экзамен на право называться разработчиком. Ничего такого в этом экзамене нет, человек просто должен показать, что он может в принципе такие вещи делать. вот в Debian GNU/Linux правила приема сложнее, человек иногда не может годами туда попасть. Дело в том, что GNU Debian -- это сообщество, которое полностью базируется на дисциплине, там нет оплачиваемых людей, зарплату получают только администраторы сборочных серверов, больше никто, поэтому такие вещи очень важны, если какой-то член core team против включения кого-то в состав разработчиков, значит есть тому резон. Человек, который вдруг решил, что ему необходимо использовать некий программный продукт, который до этого не был адаптирован к некоторому дистрибутиву, может этот продукт скачать с сайта производителя, собрать из исходников бинарный пакет, и поместить результат работы в хранилище, пользуясь правами члена сообщества. Не всякий человек может туда положить пакет, а только тот, который, условно говоря, сдал экзамен на право называться разработчиком. Ничего такого в этом экзамене нет, человек просто должен показать, что он может в принципе такие вещи делать.  Вот, допустим, в Debian GNU/Linux правила приема сложнее, человек иногда не может годами туда попасть. Дело в том, что Debian -- это сообщество, которое полностью базируется на дисциплине. Там нет оплачиваемых людей, зарплату получают только администраторы сборочных серверов, больше никто, поэтому такие вещи там очень важны, если какой-то член core team против включения кого-то в состав разработчиков, значит есть тому резон.
Line 25: Line 26:
В хранилище помещают исходный и собранный варианты программного продукта, адаптированного в местной дисциплине сборки, помещают не абы кто, а те самые мейнтейнеры. Пакет попадает в хранилище не сразу. Первым делом происходит проверка его на пригодность, на то, насколько правильно в нем соблюдена дисциплина сборки программных продуктов для хранилища (в случае Альт Линукс -- это Сизиф, и проверка называется sisyphus-check). Дисциплина оформления пакетов в Сизиф -- это подробная штука, существуют строгие рекомендации, что можно делать, а что нельзя, и фактические мейнтейнер закачивает в это хранилище не бинарный пакет, который он собрал руками, а адаптированный пакет с исходными текстами (исходный пакет), и специальный робот берет этот пакет, и не бия в бубен и не глядя по сторонам и тупо собирает его по тем правилам, которые внутри пакета заключены. Если по этим правилам пакет собирается, значит он, в числе прочего, соответствует дисциплине сборки пакетов. Если он не собирается, т.е. автоматом в изолированном окружении эти исходные тексты нельзя превратить в бинарный продукт, значит автор там у себя бил в какой-то непонятного диаметра бубен и такой пакет в хранилище не помещается. В хранилище мейнтейнеры помещают исходный и собранный варианты программного продукта, адаптированного к местной дисциплине сборки. Пакет попадает в хранилище не сразу. Первым делом происходит проверка его на пригодность, на то, насколько правильно в нем соблюдена дисциплина сборки программных продуктов для хранилища (в случае Альт Линукс -- пакет помещается в хранилище под названием Сизиф, и проверка называется sisyphus-check). Дисциплина оформления пакетов в Сизиф -- это подробное описание, достаточно строгие рекомендации, что можно делать, а что нельзя, и фактически мейнтейнер закачивает в это хранилище не бинарный пакет, который он собрал руками, а адаптированный пакет с исходными текстами (исходный пакет), и специальный робот берет этот пакет, и собирает его по тем правилам, которые внутри пакета заключены. Если по этим правилам пакет собирается, значит, он соответствует дисциплине сборки пакетов. Если он не собирается, т.е. автоматом в изолированном окружении исходные тексты не удается превратить в бинарный продукт, значит мейнтейнер у себя использовал не такое окружение или забыл что-то еще, и такой пакет в хранилище не помещается.
Line 29: Line 30:
  * проверяется формальное соответствие правилам оформления программных продуктов для сизифа и   * проверяется формальное соответствие правилам оформления программных продуктов для Сизифа и
Line 32: Line 33:
Было бы неплохо, если бы где-то были какие-то правила по тестированию, чтобы вместе с программным продуктов приезжал некий набор тестов, на которых бы он запускался и еще и работал, но вот такого не происходит, просто потому что это не всегда легко организовать. Если кто работал в промышленном программировании, знает что система тестирования занимает процентов 50 от общего времени разработки, и если авторы этого не сделали, допустим, автор три года разрабатывал программный продукт, фактически, чтобы написать полную систему тестов, нужно еще три года. кто это будет делать. То есть если сразу они от автора не приезжают, то их и нет. Если он от автора приезжают, то до какой-то степени протестировать тоже можно. Было бы неплохо, если бы где-то были какие-то правила по тестированию, чтобы вместе с программным продуктов подготавливался некий набор тестов, на которых бы он запускался и работал, но такого не происходит, просто потому что это не всегда легко организовать. Если кто работал в промышленном программировании, он знает, что система тестирования занимает процентов 50 от общего времени разработки, и если авторы этого не сделали, то это очень сложно. Допустим, автор три года разрабатывал программный продукт, значит, чтобы написать полную систему тестов, нужно еще три года.
Line 37: Line 38:
 * тот факт, что он им пользуется и не видит никаких ошибок, как раз и есть если не лучший, то весьма эффективный способ тестирования. В конце концов, мало ли какие роботы какие программы как тестируют, а тут человек с помощью программы что-то делает, работает, она у него работает, и он на этом основании помещает ее в хранилище, оно же ему нужно, вот оно это и делает.  * тот факт, что он им пользуется и не видит никаких ошибок, как раз и есть если не лучший, то весьма эффективный способ тестирования. В конце концов, мало ли какие роботы какие программы как тестируют, а тут человек с помощью программы что-то делает, работает, она у него работает, и он на этом основании помещает ее в хранилище.
Line 39: Line 40:
Тут стоит заметить, что процедура сборки -- превращения исходного текста в бинарный, результирующий программный продукт в изолированном окружении, в нашем хранилище Сизиф из известных во всем мире наиболее продвинутая и технологичная. В Debian все очень неплохо устроено, примерно также, но есть там некие тонкие различия. Что касается других дистрибутивов, то там пожиже. Это достаточно непростой процесс, могу отослать к статьям Димы Левина про технологию сборки Сизиф и про hasher (ссылки?) -- инструмент, который позволяет организовывать изолированное окружение и сборку. Это и есть те преимущества, которые сообщество вокруг дистрибутива предоставляет мейнтейнеру. Когда мейнтейнер пакета, условно говоря, просто помещает во входную очередь для сборки некий программный продукт, предварительно его оформив как надо, он соберется, проверяется, проверяются также всякие хитрости, связанные с интеграцией его в общую среду хранилища. Это дает гарантию, что, если ошибок не произошло, то этот пакет никому не навредит и не войдет в конфликт с чем-то еще.
Line 41: Line 42:
==== Технологические преимущества хранилища ====

В первый день лектор говорил, что сообщество вокруг дистрибутива предоставляет мейнтейнеру некоторые технологические преимущества, так вот это они и есть. Когда ты (мейнтейнер пакета), условно говоря, просто поместить во входную очередь для сборки некий программный продукт, предварительно его оформив как надо, он соберется, проверится, всякие хитрости, связанные с интеграцией его в общую среду этого хранилища проверится, и ты будешь гарантирован, что если ошибок не произошло, то ты никому не навредил, и значит, в следующий раз, когда ты свой же программный продукт себе же на компьютер поставишь, он не войдёт в конфликт с чем-то ещё.
Тут стоит заметить, что процедура сборки -- превращения исходного текста в бинарный, результирующий программный продукт в изолированном окружении, в нашем хранилище Сизиф из известных во всем мире наиболее продвинутая и технологичная. В Debian все устроено примерно так же, но есть некие тонкие различия. Что касается других дистрибутивов, то там пожиже. Это достаточно непростой процесс, могу отослать к статьям Димы Левина про технологию сборки Сизиф и про hasher (ссылки?) -- инструмент, который позволяет организовывать изолированное окружение и сборку.
Line 47: Line 46:
Мы в прошлый раз говорили про разделяемый библиотеки. Поскольку программные продукты в хранилище взаимодействуют друг с другом: например, программы, написанные для графической подсистемы, они пользуются целым большим множеством соответствующих программных инструментов, интерфейсной графической библиотекой, математической библиотекой (мы о ней говорили), утилитами какими-то, которые вызываются при работе программы. Каждый из этих элементов на самом деле является отдельным программным продуктом и лежит в хранилище отдельно от другого, отдельным пакетом. Мы в прошлый раз говорили про разделяемые библиотеки. Поскольку программные продукты в хранилище взаимодействуют друг с другом, например, программы, написанные для графической подсистемы, пользуются большим множеством соответствующих программных инструментов, интерфейсной графической библиотекой, математической библиотекой, различными утилитами, которые вызываются при работе программы. Каждый из этих элементов на самом деле является отдельным программным продуктом и лежит в хранилище отдельным пакетом.
Line 49: Line 48:
Именно хранилище сизиф и именно в этом смысле небезопасно для повседневного использования. Понятно почему, допустим я, сопровождающий пакета, допустим, gtk (GIMP Toolkit, популярная интерфейсная библиотека графической среды, используемая многими программными продуктами), принимаю решение, что новая версия gtk, со всякими изменениями внутри, она очень хороша и я ее естественным образом у себя дома использую, и естественным образом кладу в хранилище. Что при этом происходит? Все программные продукты, которые требуют библиотеку gtk, становятся нерабочими. Потому что, библиотека новая, программные старые, собраны с предыдущей версией библиотеки, которой уже нет, вместо него я заложил новую версию, старая удалилась. Попытка воспользоваться вот этим множеством пакетов в текущем состоянии, с условием, что я туда положил новую библиотеку, приведет к тому, что библиотека эта обновится, а все другие пакеты, от нее зависящие, удалятся на вашей машине, поэтому у них есть неудовлетворенная зависимость. Это немедленно заметит сообщество, особенно те люди, которые используют сизиф в качестве повседневного программного окружения, и за мною как за заварившим кашу, потянутся мейнтейнеры всех других программных продуктов, которые используют этот самый gtk, пересобирать свои программные продукты с поддержкой этой самой новой версии gtk. В какой-то момент ситуация вокруг gtk стабилизируется, потому что те мейнтейнеры, которым это интересно, поднимут свои версии, а те, которым это неинтересно и которых мы давно не встречали на просторах интернета, они про это дело забудут и программы останутся неработоспособными по факту, и ситуация стабилизируется. Но потом начнётся еще что-нибудь, изменится версия какого-нибудь tcl (программного интерпретатора), и опять все начнётся по новой. Это такое вот вечно нестабильно хранилище всего, и название Сизиф как нельзя лучше отражает суть работы: вот ты значит старался-старался, компилировал-компилировал, исправлял причудливую мысль автора этой программы, который считает, что нужно заводить в корневом каталоге каталог /progs и туда все записывать, или что-нибудь в этом духе, наконец, все ошибки исправил, выложил это дело в сизиф, получил обратную связь от пользователей, еще раз какие-то ошибки исправил, а через два дня вышла новая версия этой самой программы. Значит, все, значит камень скатывается обратно и все начинается сначала. Хранилище Сизиф именно в связи с этим небезопасно для повседневного использования. Допустим, сопровождающий пакета, gtk (популярная интерфейсная библиотека графической среды, используемая многими программными продуктами), принимает решение, что новая версия gtk, со всякими изменениями внутри, очень хороша, и кладет ее в хранилище. Что при этом происходит? Все программные продукты, которые требуют библиотеку gtk, становятся нерабочими. Потому что библиотека новая, программы старые, собраны с предыдущей версией библиотеки, которой уже нет, вместо нее есть новая версия, а старая удалилась. Попытка воспользоваться этим множеством пакетов при таком состоянии хранилища, приведет к тому, что библиотека эта обновится, а все другие пакеты, от нее зависящие, удалятся на вашей машине, потому что у них есть неудовлетворенная зависимость. Это немедленно заметит сообщество, особенно те люди, которые используют Сизиф в качестве повседневного программного окружения, и за мейнтейнером gtk потянутся мейнтейнеры других программных продуктов, которые используют gtk, пересобирать свои программные продукты с поддержкой новой версии gtk. В какой-то момент ситуация вокруг gtk стабилизируется, потому что те мейнтейнеры, которым это интересно, поднимут свои версии, а те, которым это неинтересно и которых мы давно не встречали на просторах интернета, про это дело забудут, а программы останутся неработоспособными. Но если мейнтейнера у программы нет, практически это значит, что ее никто не использует. Сизиф --- это такое вечно нестабильно хранилище всего, и название как нельзя лучше отражает суть работы: вот ты значит старался-старался, компилировал-компилировал, исправлял причудливую мысль автора этой программы, наконец, все ошибки исправил, выложил в Сизиф, получил обратную связь от пользователей, еще раз какие-то ошибки исправил, а через два дня вышла новая версия этой программы. Значит, камень скатывается обратно и все начинается сначала.
Line 53: Line 52:
Для того, чтобы этот процесс как-то упорядочить, некое подмножество значимых программных продуктов в этом самом хранилище регулярно, скажем, два раза в год (так принято в сизифе) подвергается процедуре под названием заморозка. Замораживается весь сизиф со словами: вот сейчас, в течение месяца-двух происходит заморозка, в течение которого никакие обновления версий внутри этих программных продуктов недопустимы, если только версия обновляется вместе с устранением критических ошибок. Единственное, что разрешается делать, это устранять критические и вообще любым ошибки в ваших программных продуктах, если такие устранения появились, и вообще заниматься только этим, не смотреть в сторону новых версий а смотреть на имеющиеся, из них удалять ошибки и вообще заниматься притиркой, усушкой и утруской. В какой-то момент сообществу это дело надоедает, т.к. сообщество хочет все время новое все, и такой вот снимок достаточно стабильного состояния сизифа, когда ситуация с новой библиотекой, которая все завалила -- исправлена, этот снимок под названием ветка (branch) откладывается в сторону, после чего в этой ветке некоторое время по инициативе дистростроителей, то есть людей, которые будут делать дистрибутив, еще продолжаются какие-то изменения, но по инерции. Все, сообщество работает дальше над сизифом, который размораживается, через неделю приходит в абсолютно нерабочее состояние, потому что все туда накидают обновлений и экспериментируют вовсю, а что касается ветки, то в идеале ее стабильность может только увеличиваться с течением времени, потому что туда будут помещать исправления ошибок, если кто-то в этом заинтересован. Для того, чтобы этот процесс как-то упорядочить, некое подмножество значимых программных продуктов в этом самом хранилище регулярно, скажем, два раза в год (так принято в Сизифе) подвергается процедуре под названием заморозка. Замораживается весь Сизиф со словами: вот сейчас, в течение месяца-двух происходит заморозка, в течение которой никакие обновления версий этих программных продуктов недопустимы, кроме случаев, если программа обновляется вместе с устранением критических ошибок. Единственное, что разрешается делать, это устранять критические и вообще любые ошибки в ваших программных продуктах, если такие устранения появились, заниматься только этим, не смотреть в сторону новых версий, а смотреть на имеющиеся, из них удалять ошибки. В какой-то момент сообществу это дело надоедает, т.к. сообщество хочет все время новое все, и снимок достаточно стабильного состояния Сизифа, когда ситуация с новой библиотекой, которая все завалила -- исправлена, откладывается в сторону под названием ветка (branch), после чего в этой ветке некоторое время по инициативе дистростроителей, то есть людей, которые будут делать дистрибутив, еще продолжаются какие-то изменения, но по инерции. А сообщество работает дальше над Сизифом, который размораживается, через неделю приходит в абсолютно нерабочее состояние, потому что все туда накидают обновлений и экспериментируют вовсю, а что касается ветки, то в идеале ее стабильность может только увеличиваться с течением времени, потому что туда будут помещать исправления ошибок, если кто-то в этом заинтересован.
Line 57: Line 56:
Кто заинтересован в том, чтобы исправлять ошибки в наборе ПО, который уже не развивается, потому что это ветка. Заинтересованы производители дистрибутивов, т.е. продуктов, которые распространяются и фирма за распространение этих продуктов хочет получить какие-то бонусы, начиная с продажи коробок, кончая внедрением в российские школы. Допустим, какая-то фирма, допустим, Альт Линукс, хочет на базе сизифа сделать дистрибутив под названием ALT Linux Junior. Еще ни у кого настолько не поплыла крыша, чтобы делать это на базе сизифа. Разумеется, так делать никто не будет. Берется ветка, в которой все уже более или менее устаканено, никаких строгих противоречий между программными продуктами внутри нету, берется некое подмножество, поскольку дистрибутив отличается от хранилища тем, что в него входят только нужные программные продукты, хотя, некоторые нужные и не входят. Кто заинтересован в том, чтобы исправлять ошибки в наборе ПО, который уже не развивается, потому что это ветка? Заинтересованы производители дистрибутивов, т.е. продуктов, которые распространяются и за распространение которых фирма хочет получить какие-то бонусы, начиная с продажи коробок, заканчивая внедрением в российские школы. Дистрибутивы делаются не на базе Сизифа. Берется ветка, в которой все уже более или менее устаканено, нет никаких строгих противоречий между программными продуктами, берется некое подмножество, поскольку дистрибутив отличается от хранилища тем, что в него входят только нужные программные продукты, и называется дистрибутивом.
Line 59: Line 58:
Есть некоторая доля содержимого, входящего в дистрибутив, но не в хранилище -- это картинки, специальные версии программных продуктов, в которых что-то перенастроено для тупых, инсталлятор, хотя он у нас весь в сизифе лежит, но мы как Debian, а у других дистрибутивов инсталлятор, как правило, пишется самостоятельно. Есть какая-то часть, в этих программных продуктах, которые даже ветке не принадлежат, но вот остальная часть берется из ветки, и дистростроитель выяснит, что от исправления ошибок зависят потребительские свойства этого дистрибутива, то в ветку продолжают вносить какие-то изменения. Вот, собственно, вам и технологических цикл. Постоянно нестабильное хранилище, в которые все постоянно помещают самые свежие версии программ, лишь бы они работали у них самих, два раза в год осуществляемых процесс заморозки, который сначала приводится в относительно стабильное состояние, потом сизиф отпускается, а сфотографированный стабильный срез продолжает жить своей жизнью, его жизнь имеет две цели * организация дистрибутивов на его основе * для тех людей, которые взяли готовый дистрибутив и им потребовалось что-то из стабильного среза хранилища. Вы взяли дистрибутив, например, lite, в котором многих программ нет, а где они есть? они есть в соответствующей ветке, из которой был сделан этот дистрибутив. Ровно так. Есть некоторая доля содержимого, входящего в дистрибутив, но не в хранилище -- это картинки, специальные версии программных продуктов, в которых что-то перенастроено, инсталлятор (хотя у нас он весь в Сизифе лежит, как в Debian, а у других дистрибутивов инсталлятор, как правило, пишется самостоятельно). Есть какая-то часть этих программных продуктов, которые даже ветке не принадлежат, но остальная часть берется из ветки. Дистростроитель понимает, что от исправления ошибок зависят потребительские свойства дистрибутива, и в ветку продолжают вносить какие-то изменения. Вот, собственно, технологический цикл: Постоянно нестабильное хранилище Сизиф, в которые постоянно помещают самые свежие версии программ, два раза в год осуществляется процесс заморозки, который приводит хранилище в относительно стабильное состояние, потом Сизиф отпускается, а сфотографированный стабильный срез продолжает жить своей жизнью, и его жизнь имеет две цели
 * организация дистрибутивов на его основе
 * ресурс для тех людей, которые взяли готовый дистрибутив, но которым потребовалось что-то еще из стабильной ветки хранилища.
Line 63: Line 64:
Еще одно свойство бывает характерно. Есть хранилище, объявлено стабильным. В нем запрещается делать обновления, за исключением обновлений по безопасности и исправлений грубых ошибок. Что если мы хотим пользуясь программным окружением из стабильного хранилища воспользоваться суперновой программой, которой либо вообще во времена стабилизации ветки в ней не было, либо со времен стабилизации она серьёзно обновилась. Болезнь новых версий у всех есть, даже у тех осторожных людей, которые не пользуются сизифом, а пользуются дистрибутивами. Для них есть отдельное небольшое хранилище, которые поддерживается таким же сообществом больных новыми версиями, которое называется backports. Берутся пакеты из сизифа и пересобираются в окружении ветки. Предполагается, что такого рода пересборка проходит (а бывает, что нет, допустим нужна более свежая версия компилятора), предполагается что использование пакетов из backports не портит стабильности ветки, хотя это никто не гарантирует. В любом случае, это намного лучше, чем пытаться одновременно брать пакеты со стабильной ветки и из сизифа. Это уже технология достаточно полная. Понятно, что дистрибутивов может быть много разных, школьных у нас 4 разных. Есть еще одно ответвление в этом технологическом процессе. Пусть есть хранилище, которое объявлено стабильным --- ветка. В нем запрещается делать обновления, за исключением обновлений по безопасности и исправлений грубых ошибок. Что если мы хотим, пользуясь программным окружением этого стабильного хранилища, воспользоваться суперновой программой, которой либо вообще во времена стабилизации ветки в ней не было, либо со времен стабилизации она серьёзно обновилась? Болезнь новых версий у всех есть, даже у тех осторожных людей, которые не пользуются Сизифом, а пользуются дистрибутивами. Для них есть отдельное небольшое хранилище, которые поддерживается таким же сообществом больных новыми версиями, которое называется backports. Берутся пакеты из Сизифа и пересобираются в окружении ветки. Предполагается, что такого рода пересборка проходит (а бывает, что нет, допустим нужна более свежая версия компилятора), предполагается что использование пакетов из backports не портит стабильности ветки, хотя это никто не гарантирует. В любом случае, это намного лучше, чем пытаться одновременно брать пакеты со стабильной ветки и из Сизифа.
Line 65: Line 66:
Нестабильное хранилище большое, стабильный срез хранилища -- регулярный, изготовление дистрибутивов как наборов ПО из стабильного хранилища + всякая дополнительная обвязка вроде специфики инсталлятора. ##Нестабильное хранилище большое, стабильный срез хранилища -- регулярный, изготовление дистрибутивов как наборов ПО из стабильного хранилища + всякая дополнительная обвязка вроде специфики инсталлятора.
##Картинку бы, похожую на дебиановскую (в Википедии, в статье про Debian есть картинка, как у них репозитории связаны).
Line 126: Line 128:
|| 20 || 1 || 1 || 1 || || 1 || PavelSutyrin, VladimirLysikov, MaximByshevskiKonopko || || || || 50 || 1 || 1 || 1 || || 1 || PavelSutyrin, VladimirLysikov, MaximByshevskiKonopko || || ||

Сообщество вокруг дистрибутива

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

В случае дистрибутивов роль core team -- определять стратегическое направление, в котором развивать дистрибутив, и не давать проявляться субъективным факторам, например ленивым или просто ушедшим на другую деятельность разработчикам. Необходимо, чтобы и веб-браузер был на уровне, и чтобы ядро ОС было достаточно защищенное и современное, а если какой-то сторонний человек, не входящий в core, и вообще изредка участвующий в этом сообществе, занимается ключевой частью дистрибутива, то может получиться такая ситуация: в ядре ОС давно обнаружены и исправлены ошибки, а в дистрибутиве все еще находится старое.

Так вот, по отношению к дистрибутиву у core team сохраняются все те же функции, что и по отношению к обычной свободной программе, а понятие разработчика слегка размывается, т.к. основной фигурой на этом месте становится мейнтейнер, он же сопровождающий. Это человек, который имеет некоторую необходимость использовать программный продукт в рамках нашего дистрибутива, и эта необходимость настолько сильная, что он готов сам заниматься сборкой этого продукта, т.е. превращением из исходного кода в бинарный, и адаптацией его под конкретные условия, под дисциплину сборки программных продуктов, принятую в нашем дистрибутиве. Более того. в действительности дистрибутив -- это конечный продукт некоей технологии, которая в качестве базового элемента имеет не дистрибутив, а то что называется хранилищем(англ. repository).

Хранилище

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

Мейнтейнеры

Человек, который вдруг решил, что ему необходимо использовать некий программный продукт, который до этого не был адаптирован к некоторому дистрибутиву, может этот продукт скачать с сайта производителя, собрать из исходников бинарный пакет, и поместить результат работы в хранилище, пользуясь правами члена сообщества. Не всякий человек может туда положить пакет, а только тот, который, условно говоря, сдал экзамен на право называться разработчиком. Ничего такого в этом экзамене нет, человек просто должен показать, что он может в принципе такие вещи делать. Вот, допустим, в Debian GNU/Linux правила приема сложнее, человек иногда не может годами туда попасть. Дело в том, что Debian -- это сообщество, которое полностью базируется на дисциплине. Там нет оплачиваемых людей, зарплату получают только администраторы сборочных серверов, больше никто, поэтому такие вещи там очень важны, если какой-то член core team против включения кого-то в состав разработчиков, значит есть тому резон.

Дисциплина оформления пакетов

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

То есть

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

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

Далее, предполагается, что если мейнтейнер поместил пакет в хранилище, то он

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

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

Тут стоит заметить, что процедура сборки -- превращения исходного текста в бинарный, результирующий программный продукт в изолированном окружении, в нашем хранилище Сизиф из известных во всем мире наиболее продвинутая и технологичная. В Debian все устроено примерно так же, но есть некие тонкие различия. Что касается других дистрибутивов, то там пожиже. Это достаточно непростой процесс, могу отослать к статьям Димы Левина про технологию сборки Сизиф и про hasher (ссылки?) -- инструмент, который позволяет организовывать изолированное окружение и сборку.

Зависимости между пакетами. Обновления и стабильность

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

Хранилище Сизиф именно в связи с этим небезопасно для повседневного использования. Допустим, сопровождающий пакета, gtk (популярная интерфейсная библиотека графической среды, используемая многими программными продуктами), принимает решение, что новая версия gtk, со всякими изменениями внутри, очень хороша, и кладет ее в хранилище. Что при этом происходит? Все программные продукты, которые требуют библиотеку gtk, становятся нерабочими. Потому что библиотека новая, программы старые, собраны с предыдущей версией библиотеки, которой уже нет, вместо нее есть новая версия, а старая удалилась. Попытка воспользоваться этим множеством пакетов при таком состоянии хранилища, приведет к тому, что библиотека эта обновится, а все другие пакеты, от нее зависящие, удалятся на вашей машине, потому что у них есть неудовлетворенная зависимость. Это немедленно заметит сообщество, особенно те люди, которые используют Сизиф в качестве повседневного программного окружения, и за мейнтейнером gtk потянутся мейнтейнеры других программных продуктов, которые используют gtk, пересобирать свои программные продукты с поддержкой новой версии gtk. В какой-то момент ситуация вокруг gtk стабилизируется, потому что те мейнтейнеры, которым это интересно, поднимут свои версии, а те, которым это неинтересно и которых мы давно не встречали на просторах интернета, про это дело забудут, а программы останутся неработоспособными. Но если мейнтейнера у программы нет, практически это значит, что ее никто не использует. Сизиф --- это такое вечно нестабильно хранилище всего, и название как нельзя лучше отражает суть работы: вот ты значит старался-старался, компилировал-компилировал, исправлял причудливую мысль автора этой программы, наконец, все ошибки исправил, выложил в Сизиф, получил обратную связь от пользователей, еще раз какие-то ошибки исправил, а через два дня вышла новая версия этой программы. Значит, камень скатывается обратно и все начинается сначала.

Заморозка. Стабильные ветки

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

Дистрибутивы

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

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

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

backports

Есть еще одно ответвление в этом технологическом процессе. Пусть есть хранилище, которое объявлено стабильным --- ветка. В нем запрещается делать обновления, за исключением обновлений по безопасности и исправлений грубых ошибок. Что если мы хотим, пользуясь программным окружением этого стабильного хранилища, воспользоваться суперновой программой, которой либо вообще во времена стабилизации ветки в ней не было, либо со времен стабилизации она серьёзно обновилась? Болезнь новых версий у всех есть, даже у тех осторожных людей, которые не пользуются Сизифом, а пользуются дистрибутивами. Для них есть отдельное небольшое хранилище, которые поддерживается таким же сообществом больных новыми версиями, которое называется backports. Берутся пакеты из Сизифа и пересобираются в окружении ветки. Предполагается, что такого рода пересборка проходит (а бывает, что нет, допустим нужна более свежая версия компилятора), предполагается что использование пакетов из backports не портит стабильности ветки, хотя это никто не гарантирует. В любом случае, это намного лучше, чем пытаться одновременно брать пакеты со стабильной ветки и из Сизифа.

Относительно объёмов --- хранилище содержит около 9000 пакетов. Типичный дистрибутив на DVD --- порядка 4000 пакетов, на CD --- порядка 800. Двухслойный DVD --- 8000-9000 пакетов.

Посмотрим репозиторий

lftp ftp.altlinux.org

lftp ftp.altlinux.org:/pub> ls
lrwxrwxrwx    1 ftp      ftp            30 Jun 15  2007 Mozilla -> distributions/ALTLinux/Mozilla
lrwxrwxrwx    1 ftp      ftp            33 Jun 15  2007 OpenOffice -> distributions/ALTLinux/OpenOffice
drwxr-sr-x   10 ftp      ftp          4096 Jul 24 12:49 beta
drwxr-xr-x    6 ftp      ftp          4096 Aug 01  2006 distributions
drwxr-xr-x    5 ftp      ftp          4096 Apr 02  2006 docs
drwxrwsr-t    3 ftp      ftp          4096 Jun 10  2006 mirrors
drwxr-sr-x    5 ftp      ftp          4096 Mar 11  2003 partners
drwxr-xr-x   72 ftp      ftp          4096 Jul 09 14:51 people
drwxr-xr-x    3 ftp      ftp          4096 Jun 25  2004 security

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

lftp ftp.altlinux.org:/pub/distributions> ls
drwxr-xr-x   13 ftp      ftp          4096 Jul 30 21:49 ALTLinux
drwxr-xr-x    3 ftp      ftp          4096 Feb 21  2006 FreeMusic
drwxr-xr-x    3 ftp      ftp          4096 Feb 21  2006 OpenMusic
drwxr-xr-x    3 ftp      ftp          4096 Jun 15  2007 archive

Это по именам дистрибутивов.

lftp ftp.altlinux.org:/pub/distributions/ALTLinux> ls
drwxr-xr-x    3 ftp      ftp          4096 Feb 13  2003 2.2
drwxr-xr-x    4 ftp      ftp          4096 Jul 01  2004 2.3
drwxr-xr-x    3 ftp      ftp          4096 Nov 03  2004 2.4
drwxr-xr-x   10 ftp      ftp          4096 Mar 03  2006 3.0
drwxr-xr-x    7 ftp      ftp          4096 Jun 05 20:14 4.0
drwxr-xr-x    3 ftp      ftp          4096 May 07 00:12 4.1
drwxrwsr-x    4 ftp      ftp          4096 May 31  2007 Daedalus
drwxr-xr-x   14 ftp      ftp          4096 Aug 01 07:09 Sisyphus
drwxrwsr-x    8 ftp      ftp          4096 May 12 09:57 backports
drwxr-xr-x    5 ftp      ftp          4096 Jul 30 21:37 old
drwxr-xr-x    9 ftp      ftp          4096 Dec 09  2007 updates
  • Sisyphus -- это хранилище Сизиф,

  • 2.2, 2.3, ..., 4.1 -- это стабильные ветки, сделанные в своё время.

  • backports -- это backports (внутри -- по веткам)

  • updates -- обновления к веткам и дистрибутивам (по отдельности, т.к. одно и то же может обновляться по-разному из-за особенностей допилки в дистрибутивах)

{00:47:27}


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

50

1

1

1

1

PavelSutyrin, VladimirLysikov, MaximByshevskiKonopko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080720/01Repository (last edited 2008-10-09 18:46:34 by MaximByshevskiKonopko)