Система пакетов
Модули
Готов? |
Название модуля |
Чтение (ак. ч.) |
Подготовка (астр. ч.) |
Написание (дни) |
уровень |
Maintainer |
Started |
Should be done |
End date |
|
1 |
1 |
1 |
1 |
|||||
|
1 |
1 |
1 |
1 |
|||||
|
2 |
2 |
2 |
2 |
|
|
|
|
|
|
Готово: 0 (0%) |
0 |
|
0 |
|
|
|
|
|
|
Не готово: 2 (100%) |
2 |
|
2 |
|
|
|
|
|
0% 
Необходимые знания
Материалы
Диктофонная запись: http://esyr.org/lections/audio/uneex_2008_summer/uneex_08_05_07.ogg
Полиси
На данный момент для координирования работ используется макрос ExtractModules (тот же, что и в PspoModules). Возможно, впоследствии будет написано нечто более специфичное для данных работ.
- Над каждым модулем работает один расшифровщик (указывается первым в списке сопровождающих модуль),один переводчик (указывается вторым в списке) и минимум один технический редактор (тот, кто вычитывает, указывается третьим в списке).
- Разбивка прогресса по процентам:
0%
Сырой конспект
20%
Дешифрованный конспект
50%
Конспект, переведенный на русский язык
70%
Вычитанный конспект
90%
Иллюстрирование, расстановка ссылок, перенос в модули
100%
Результат работ над частью лекций проверен FrBrGeorge
- Как только Вы считаете, что закончили свою часть работы, просьба установить соответствующее количество процентов
- Промежуточное количество процентов в промежуточных сохранениях приветствуется
Пожелания к ролям
Расшифровка ? по возможности полное восстановление структуры и смысла лекции по конспектам и (если есть необходимость) по аудиозаписям. в эту задачу входит расстановка имеющихся иллюстраций (typescript, konsole.log, снимки экрана)
Перевод на русский ? выравнивание стилистки и корректировка владения русским языком. Просьба не очень самовыражаться (чтобы не создавать стилистического разнобоя)
Вычитка ? проверка получившегося текста на (1) соответствие действительности (2) доходчивость (в том числе на предмет нехватки иллюстраций)
Лекции
Дистрибутив
Если мы откроем книгу Кернигана-Пайка, то она будет описвыать какие-то утилиты, но у нее не уделяется много внимания тому факту, откуда это программное окружение взялось. Много ли там написано про то, откуда взялась утилита grep? Это отражает такую 15---20 летней давности идеологию unix-way, которая работала с большими, но постишими объектами типа unix, и никакой серьезной опасности в том, что все это разрастется в непостижимой снежный ком, не чувствовалось. И это чувствуется из книг тех времен. Сама система была ориентирована на универсала, на человека-гору, который знает все про все: он же и администратор, и программист, и железячник. По этой причине о какой-то сегментации, распиливании окружения на части и не думали. Подразумевалось, если вы собираетесь с этим работать, то вы собираетесь все это пройти. И тут чувствуется отличие линукс от юникс.
Рассуждение о том, как вообще может формироваться состав прогр. окружения, состав дистрибутива, то, из чего формуируется ОС. Поддхзода два: * Монолит. Есть хозяин-вендор, который предоставляет всю ту функциональность, которая нужна для работы в этом прогр. окруж. Люди сами пишут ядро, шелл, утилиты, исстемные утилиты. Если расширить концепцию представления всего в виде текста и работы с сист. как изм. текста, то можно добавить приложения. На самом деле, нам знакомы подобного рода истсемы. Если нам чего-то не хватает, то мы вынуждены где-то со стороны добывать новые приложения, что не были пробуманы первым вендором. Вот этот вариант, когда практически 100 процентов приложений поставляется, знаком нам, но с Линуксом связан слабо. Например, Windows, но не только он, но и любая ОС, которая разрабатывается по закрытой модели. ... Но это очень большая работа, и ее не проделывают вендоры. ... Помимо виндовса, любая закрытая ОС будет представлять собой монолитное сооужение. * Много вендоров, каждый пишет свою часть. Чем эта схема очевидно хороша: если есть некий профессионал, который хорошо пишет компилятор С, то хорошо, чтобы он бы ее и писал. Или фирма, которая делает суперкрутую систему печати, вот пусть она ее и делает. Все это возможно только в том случае, если все эти вндоры договорятся о том, чтобы свалить все в одну кучу и вместе использовать. В случае несвободной разработки больше двух вендоров договориться не могут. В случае с линукс вендоры наоборот хотят, чтобы их продукты использовали в как можно большем количестве мест. Очевидное преимущество ячеистой структуры в том, что каждый компонент будет передовым.
В случае с монолитной разработкой у вендора спрашивают, насоклько оно совместимо с ПОСИХ и надеяться на то, что оно будет работать.
Что касается линукса, то мы будем более-менее уверены, что эта часть будет работать приблизительно так же, как и на соседнем. Главный недостаток очевиден --- без участия интегратора все это будет не работать. Еще один недостаток --- дистрибутивы с разными ключевыми компонентами будут в различнрой степени несовместимы. Удобнее было бы иметь некую промежуточную схему, которая выглядит следующим образом: есть нечто под назанием базовая система, которая разрабатывеается монолитно. Она влкючает в себя ядро, системные утилиты, часть пользовательских утилит и более-менее совпадает с тем, что назывлаось пользовательским окруж. В таком объеме это вполне постижимое информаци. пространство, и в таком случае можно добиться гораздо большей гармонии. По этой схеме работают все BSD-системы. При этом можно гарантировать в некотором смысле перностимость. Кроме того, в этом случае начинают работать манпейджи, поскольку пространство их замкнуто (в отличие от линукс). Тем не менее, появилась тенденция расматривать BSD-дистрибутивы вкупе с дополнительными утилитами.
Тем не менее, появлиась тенденция рассм. окружения за рамки голого посикса. Кроме того, разбухание этого компонента делает его тяжелым и неуправляемым.
Тем не менее, монолитная структура --- существовала во времена юних, когда все это помещалось в одну голову.
Далее про то, как все это уживается.
Пакет
FHS
В дистр линукс, да и вообще в любом, кто соответствует BSD. Есть опр. структура:
/ /sbin /bin /usr /bin /lib /lib /etc
Лектор так легко перечисляет все эти директории, поскольку есть стандарт, и все линуксы ему следуют. Есть стандарт, в котором описано, где лежат файлы различного применения. В /bin/ лежат программы, которые нужны для старта системы, в /lib/ лежат разд. библ. D /usr/ лежит то, что не нужно для запуска. В /etc/ лежат конфиги.
Каоке это отношение имеет к молульной структуре? Посокльку все каталоги стандартизованы, автор конкретного прогр. продукта не заморачивается мыслью, где что должно лежать. И поскольку есть вендор, который собирает дистрибутив, то всегда можно отследить конфликты. Например, Вася Пупкин написал игру "Лысый Сторож" и назвал ее ls.
Но все не так просто. Поскольку не всегда это может вместе хорошо лежать.
Пакет
Решили мы что-то ... В точки зрения ... пакет это архив. Если мы просто возьмем архив и разархивируем его в корень, то все ляжет. Но это не так удобно... просто архивация и все, если есть задача установки и удаления. Если вы думаете, что можно просто установить программу, то вспомните про такую вещь, как одновление. Соответственно, нужен как минимум список файлов. То, есть, как минимум, нужна регистрация в системе. Конкретно: список установленных файлов, контрольные суммы (на случай изменение). Например, при изменении конф. файлов ... .
Кроме того, в процессе установки/удаления требуется запустить дополнтиельныйц сценарии, которые что-то делают. То есть, постустановочные сценарии.
Между тем, ситуаций, когда запускаются скрипты, довольно много: предустановочные, постустановочные, конфигурационные. Ментейнер пакетов предусматривает в немнекие действия, которые выполн. при разных стадиях работы с пакетом.
Приммер зависимостей: разделяемые библиотеки. Первый недостаток: размер бинарников при статической линковке. Вторая: отслеживание версий. Чем мы за это платим:
- Отслеживание зависимостей. Например gqview зависит от
libgtk imlib libjpeg libtiff
- Виртуальные пакеты
- Конфликт по файлам. Пример: vi
Все эти вещи надо отслеживать при создании дистрибутива. Причем, когда упоминается ментейнер: смешивается две вещи --- собственно разработчики и ментейнеры конкретного дитсрибутива.