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

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

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

'''Диктофонная запись:''' 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 часа.

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.org/wiki/UN%D0%98X%2C_%D0%B2%D0%B5%D1%81%D0%BD%D0%B0_2008%2C_13_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_07_%D0%BC%D0%B0%D1%8F%29

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

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

Просмотры

Личные инструменты

Навигация

инструменты

Разделы

Спецкурсы

9 семестр

7 семестр

5 семестр

3 семестр

Поиск

Инструменты

Текущая версия		Ваш текст
Строка 1:		Строка 1:
	'''Диктофонная запись:''' http://esyr.org/lections/audio/uneex_2008_summer/uneex_08_05_07.ogg		'''Диктофонная запись:''' http://esyr.org/lections/audio/uneex_2008_summer/uneex_08_05_07.ogg
-
	Если мы откроем книгу Кернигана-Пайка, то она будет описвыать какие-то утилиты, но у неё не уделяется много внимания тому факту, откуда это программное окружение взялось. Много ли там написано про то, откуда взялась утилита grep? Это отражает такую 15---20 летней давности идеологию unix-way, которая работала с большими, но постишими объектами типа unix, и никакой серьёзной опасности в том, что всё это разрастётся в непостижимой снежный ком, не чувствовалось. И это чувствуется из книг тех времён. Сама система была ориентирована на универсала, на человека-гору, который знает всё про всё: он же и администратор, и программист, и железячник. По этой причине о какой-то сегментации, распиливании окружения на части и не думали. Подразумевалось, если вы собираетесь с этим работать, то вы собираетесь всё это пройти. И тут чувствуется отличие линукс от юникс.		Если мы откроем книгу Кернигана-Пайка, то она будет описвыать какие-то утилиты, но у неё не уделяется много внимания тому факту, откуда это программное окружение взялось. Много ли там написано про то, откуда взялась утилита grep? Это отражает такую 15---20 летней давности идеологию unix-way, которая работала с большими, но постишими объектами типа unix, и никакой серьёзной опасности в том, что всё это разрастётся в непостижимой снежный ком, не чувствовалось. И это чувствуется из книг тех времён. Сама система была ориентирована на универсала, на человека-гору, который знает всё про всё: он же и администратор, и программист, и железячник. По этой причине о какой-то сегментации, распиливании окружения на части и не думали. Подразумевалось, если вы собираетесь с этим работать, то вы собираетесь всё это пройти. И тут чувствуется отличие линукс от юникс.