• На данный момент для координирования работ используется макрос ExtractModules (тот же, что и в PspoModules). Возможно, впоследствии будет написано нечто более специфичное для данных работ.

• Над каждым модулем работает один расшифровщик (указывается первым в списке сопровождающих модуль),один переводчик (указывается вторым в списке) и минимум один технический редактор (тот, кто вычитывает, указывается третьим в списке).
• Разбивка прогресса по процентам:

  0%	Сырой конспект
  20%	Дешифрованный конспект
  50%	Конспект, переведённый на русский язык
  70%	Вычитанный конспект
  90%	Иллюстрирование, расстановка ссылок, перенос в модули
  100%	Результат работ над частью лекций проверен FrBrGeorge

• Как только Вы считаете, что закончили свою часть работы, просьба установить соответствующее количество процентов
• Промежуточное количество процентов в промежуточных сохранениях приветствуется

Пожелания к ролям

• Расшифровка — по возможности полное восстановление структуры и смысла лекции по конспектам и (если есть необходимость) по аудиозаписям. в эту задачу входит расстановка имеющихся иллюстраций (typescript, konsole.log, снимки экрана)

• Перевод на русский — выравнивание стилистки и корректировка владения русским языком. Просьба не очень самовыражаться (чтобы не создавать стилистического разнобоя)

• Вычитка — проверка получившегося текста на (1) соответствие действительности (2) доходчивость (в том числе на предмет нехватки иллюстраций)

CategoryPolicy

Если мы откроем книгу Кернигана-Пайка, то она будет описвыать какие-то утилиты, но у неё не уделяется много внимания тому факту, откуда это программное окружение взялось. Много ли там написано про то, откуда взялась утилита 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

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