UNИX, весна 2008, 13 лекция (от 07 мая)

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

Версия от 23:16, 15 мая 2008; Allena (Обсуждение | вклад)
(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск

Диктофонная запись: http://esyr.org/lections/audio/uneex_2008_summer/uneex_08_05_07.ogg

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

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

В след раз последующая лекция. Надо заказать аудиторию на 21 число на 3 часа.


UNИX, весна 2008


Лекции

01 02 03 04 05 06 07 08 09 10 11 12 13 14


Календарь

Февраль
13 20 27
Март
05 12 19 26
Апрель
02 09 16 23 30
Май
07 14
Семинары

01 02 03 04 05 06 07


Календарь

Март
21
Апрель
04
Май
16 30
Июль
11 18
Август
15


Эта статья является конспектом лекции.

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