Дистрибутив

Если мы откроем книгу Кернигана-Пайка, то она будет описвыать какие-то утилиты, но у неё не уделяется много внимания тому факту, откуда это программное окружение взялось. Много ли там написано про то, откуда взялась утилита grep? Это отражает такую 15---20 летней давности идеологию unix-way, которая работала с большими, но постишими объектами типа unix, и никакой серьёзной опасности в том, что всё это разрастётся в непостижимой снежный ком, не чувствовалось. И это чувствуется из книг тех времён. Сама система была ориентирована на универсала, на человека-гору, который знает всё про всё: он же и администратор, и программист, и железячник. По этой причине о какой-то сегментации, распиливании окружения на части и не думали. Подразумевалось, если вы собираетесь с этим работать, то вы собираетесь всё это пройти. И тут чувствуется отличие линукс от юникс.

Рассуждение о том, как вообще может формироваться состав прогр. окружения, состав дистрибутива, то, из чего формуируется ОС. Поддхзода два: * Монолит. Есть хозяин-вендор, который предоставляет всю ту функциональность, которая нужна для работы в этом прогр. окруж. Люди сами пишут ядро, шелл, утилиты, исстемные утилиты. Если расширить концепцию представления всего в виде текста и работы с сист. как изм. текста, то можно добавить приложения. На самом деле, нам знакомы подобного рода истсемы. Если нам чего-то не хватает, то мы вынуждены где-то со стороны добывать новые приложения, что не были пробуманы первым вендором. Вот этот вариант, когда практически 100 процентов приложений поставляется, знаком нам, но с Линуксом связан слабо. Например, Windows, но не только он, но и любая ОС, которая разрабатывается по закрытой модели. ... Но это очень большая работа, и её не проделывают вендоры. ... Помимо виндовса, любая закрытая ОС будет представлять собой монолитное сооужение. * Много вендоров, каждый пишет свою часть. Чем эта схема очевидно хороша: если есть некий профессионал, который хорошо пишет компилятор С, то хорошо, чтобы он бы её и писал. Или фирма, которая делает суперкрутую систему печати, вот пусть она её и делает. Всё это возможно только в том случае, если все эти вндоры договорятся о том, чтобы свалить всё в одну кучу и вместе использовать. В случае несвободной разработки больше двух вендоров договориться не могут. В случае с линукс вендоры наоборот хотят, чтобы их продукты использовали в как можно большем количестве мест. Очевидное преимущество ячеистой структуры в том, что каждый компонент будет передовым.

В случае с монолитной разработкой у вендора спрашивают, насоклько оно совместимо с ПОСИХ и надеяться на то, что оно будет работать.

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

Тем не менее, появлиась тенденция рассм. окружения за рамки голого посикса. Кроме того, разбухание этого компонента делает его тяжёлым и неуправляемым.

Тем не менее, монолитная структура --- существовала во времена юних, когда всё это помещалось в одну голову.

Далее про то, как всё это уживается.

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

CategoryLectures CategoryCmc CategoryUneex