- •Возникновение и первая редакция ос unix
- •Основные понятия
- •Пользователь
- •Интерфейс пользователя
- •Привилегированный пользователь
- •Программы
- •Команды
- •Процессы
- •Перенаправление ввода/вывода
- •Руководство
- •Поля руководства
- •Краткое описание Семантическое
- •Синтаксическое
- •Описание
- •Результат
- •Использование
- •Ссылки на другие объекты
- •Родословная
- •Особенности руководств
- •Смысловая структура системы руководств
- •Утилита man
- •Утилиты whatis и apropos
- •Работа с руководствами
- •Система info
- •Что такое удобство?
- •Требования к интерфейсу unix
- •Командная строка
- •Договоренности о формате командной строки
- •Разновидности файлов
- •Обычные файлы
- •Файлы-каталоги
- •Специальные файлы
- •Связывание файлов с разными именами
- •Именованные программные каналы
- •Файлы, отображаемые в виртуальную память
- •Синхронизация при параллельном доступе к файлам
- •Принципы защиты
- •Идентификаторы пользователя и группы пользователей
- •Защита файлов
- •Управление устройствами
- •Устройство как специальный файл
- •Драйверы устройств
- •Внешний и внутренний интерфейсы устройств
- •Традиционные средства интерактивного интерфейса пользователей
- •Командные языки и командные интерпретаторы
- •Общая характеристика командных языков
- •Базовые возможности семейства командных интерпретаторов
- •Bourne-shell
- •C-shell
- •Korn-shell
- •Команды и утилиты
- •Организация команды в ос unix
- •Перенаправление ввода/вывода и организация конвейера
- •Встроенные, библиотечные и пользовательские команды
- •10. Принципы сборки и установки пакетов.
10. Принципы сборки и установки пакетов.
Наборы исходников объединяются разработчиками в пакеты.
Пакеты принято распространять в виде компрессированных архивов - файлов вида *.tar.gz (*.tgz) или *.tar.bz2 (*.tbz2, *.tbz), так называемых тарбаллов. Обычно действует правило: один тарбалл - один пакет. Очень большие пакеты могут быть поделены на несколько тарбаллов (примером чему те же XFree86 или Xorg), но делается это исключительно для удобства скачивания, все равно такой набор тарбаллов исходников сохраняет свою целостность.
Для того, чтобы программа, распространяемая в исходниках, могла выполнять свои функции, она должна быть собрана. Процесс этот в общем случае разбивается на три стадии:
1.конфигурирование;
2.собственно сборку;
3.инсталляцию.
Конфигурирование - это приведение программы в соответствие с реалиями конкретной системы. Приведение в соответствие того где все лежит и как называется. Что и проверяется в процессе конфигурирования. То есть основное назначение его - проверка так называемых зависимостей пакетов.
Понятие зависимостей - одно из основных при сборке программ. Суть его в том, что пакет pkgname1 для установки и (или) функционирования требует наличия в системе пакета pkgname2, тот, в свою очередь, может потребовать пакета pkgname3, и так далее. В качестве зависимостей выступают часто (хотя и не всегда) те самые системные библиотеки, о которых говорилось ранее.
Зависимости пакетов бывают разными. С одной стороны, различают зависимости при сборке (обычно называемые просто зависимостями - depends) и зависимости при запуске (по английски именуемые run depends).
С другой стороны, следует различать зависимости жесткие и "мягкие". Удовлетворение первых абсолютно необходимо для сборки данного пакета.
"Мягкие" зависимости данного пакета не критичны для его функционирования - удовлетворение их лишь добавляет ему дополнительные функции (которые могут оказаться и лишними).
За конфигурирование обычно отвечает сценарий, расположенный в корне дерева исходников данной программы и, по соглашению, носящий имя configure. Что именно делает конкретный конфигурационный скрипт - сугубо на совести разработчика программы. Как минимум, он обязан проверять жесткие зависимости устанавливаемого пакета и, при их нарушении, выдавать соответствующие сообщения. Кроме того, он может обеспечивать также подключение дополнительных функций - при наличии определенных условий, то есть удовлетворении зависимостей "мягких".
Если процесс конфигурирования завершается успешно, в корне дерева каталогов создается специальный файл - Makefile, в котором и фиксируются все предусмотренные разработчиком настройки, выступающие в качестве директив на следующем этапе.
Если конфигурирование прошло с ошибками, выдается соответствующее сообщение, форма которого также целиком определяется разработчиком.
Наконец, конфигурирование завершилось успешно. Наступает время следующего этапа - собственно сборки, то есть претворения исходных текстов программы в исполняемый машинный код. Этап этот распадается на несколько стадий.
Первая стадия - собственно компиляция исходного текста в бинарный код, завершающаяся формированием объектного модуля. Это - как правило, еще не готовая к запуску программа. Почему? Да потому, что в его скомпилированном коде может не быть многих стандартных функций - тех самых, которые разработчик предполагал заимствовать из разделяемых библиотек.
И потому вторая стадия - это связывание (linking, в просторечии именуемое линковкой) сгенерированного кода с необходимыми библиотечными фрагментами. Линковка может быть двух видов - статическая и динамическая. В первом случае требуемый код из библиотеки встраивается внутрь собираемой программы, после чего получается готовый к исполнению бинарный файл, более в библиотеке не нуждающийся. Это - именно тот случай, когда понятия depends и rdepends приобретают разное значение: первое оказывается шире.
Второй случай - динамической линковки, - предполагает, что библиотечный код не встраивается в программу: вместо него устанавливается только ссылка на файл библиотеки и требуемую функцию (имя которой извлекается из так называемого заголовочного файла - header-файла). И в дальнейшем, при запуске исполняемого модуля программы, соответствующие библиотечные фрагменты извлекаются с диска и присоединяются к коду программы уже только в оперативной памяти. При этом сущности depends и rdepends оказываются идентичными: библиотека, с которой программа связывается при сборке, столь же необходима и для ее запуска.
Динамическая линковка приводит как к сокращению размера исполняемого файла, так и уменьшению объема оперативной памяти, задействуемого при запуске программ.
Третий этап процесса сборки - инсталляция. Это копирование всех компонентов программы в структуру файловой системы данной машины.
По завершении всего сборочного цикла из пакета исходников должна получиться полнофункциональная, готовая к употреблению, программа, требующая лишь некоторой пользовательской настройки.
Чипсет.
Что такое чипсет?
Чипсет (ChipSet - набор чипов), или набор системной логики, представляет собой одну или несколько микросхем, специально разработанных для обеспечения взаимодействия CPU со всеми остальными компонентами компьютера. Чипсет определяет, какой процессор может работать на данной материнской плате, тип, организацию и максимальный объем используемой оперативной памяти (разве что современные модели процессоров AMD имеют встроенные контроллеры памяти), сколько и какие внешние устройства можно подключить к компьютеру. Разработкой чипсетов для десктопов занимаются 5 компаний: Intel, NVIDIA, AMD, VIA и SIS. Чаще всего чипсет состоит из 2 интегральных микросхем, называемых северным и южным мостами. Северный мост (Northbridge или, у Intel, MCH - Memory Controller Hub) обеспечивает взаимосвязь между процессором (по шине FSB - Front Side Bus), оперативной памятью (SDRAM, DDR, DDR2 и, в ближайшей перспективе, DDR3), видеокартой (интерфейсы AGP или PCI Express) и, посредством специальной шины, с южным мостом (Southbridge, или ICH - I/O Controller Hub), в котором расположены большинство контроллеров интерфейсов ввода-вывода. Некоторые северные мосты включают графическое ядро, использующее внутренний интерфейс AGP или PCI Express - такие чипсеты называются интегрированными.
К числу устройств, встроенных в южный мост, относятся контроллеры шин PCI (Peripheral Components Interconnect) и/или PCI Express, дисковых накопителей (IDE и SATA-жестких дисков и оптических приводов), встроенные звуковые, сетевые, USB- и RAID-контроллеры. Южный мост также обеспечивает нормальную работу системных часов (RTC - Real Time Clock) и микросхемы BIOS. Иногда встречаются чипсеты, состоящие только из одной микросхемы (однокомпонентные чипсеты), объединяющим функциональность обоих мостов