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

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

http://esyr.org/lections/audio/uneex_2008_summer/uneex_08_05_14.ogg

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

[править] Пакеты

Чем пакет является:

• Архивом. Достаточно распаковать его в корень, поскольку есть FHS
• Этот архив треубет дополн. действий. Регистрация в системе.
• Конфигурация.
• Зависимости. Для того, чтобы один пакет установить, надо предварительно установить все зависимые пакеты.
• Конфликты.

Чего лектор в прошлый раз не сказал: лектор не сказал об инструментах.

[править] RPM

Система установки, чборки пакетов --- RedHat Package Manager. Это установщик пакетов, утилита, которая работае т ровно с одним пакетом, лежащим ровно в одном файле. Например:

• rpm -i <file>.rpm --- установка
• rpm -e <file>.rpm --- удаление

В подтверждение того, что rpm --- архив? tcnm утилита-фильтр rpmtocpio, которая выводит файл в формате cpio. Можно его посмотреть, написав rpmtocpio | cpio -itv.

Все перечисленные свойства RPM поддерживает.

С помощью rpm можно собрать пакет. Идея состоит в следующем: что нужно, чтобы собрать пакет? Для начала нужно иметь в виду одну особенность: авторы программ знать-не знают, ведать-не ведают о существовании дистрибутива ALT Linux, и правилах структуры пакетов. Например, есть утилита eaglomode, которая устанавливается а-ля солярис: /opt/eaglemode/{bin|lib|res|etc}. ...

Это значит, что нужно модифицировать исходный код продукта, в помощь чему есть набор утилит patch, поскольку ментейнер не делает изменения с 0 для каждой версии, он оформляет эти изменения в виде патча, который потом накладывается.

Нужно соблюсти три условия:

• Оформить отличия в виде патчей
• Написать команды по сборке
• Нужно организовать предустановочный и послеудалятельный суенарий
• Заполнить паспорт пакета

Для всего это есть один файл, спекфайл, в которым всё это лежит, за исключением больших файлов, которые лежат отдельно. Иговорится, что пакеет состоит из скачанного исходника, спекфайла и дополнительных фйайлов. Это составляет src.rpm. Из этого собирается rpm.

Появляется второе понятие зависимости: зависимости, необходимые для сборки пакета.

Из этого можно сделать вывод, что rpm для обычного пользователя программа не очень удобная. Поскольку при попытке установить покет может оказаться, что не удовлетворены изх зависимости, для них не удовлетворены их и так дале. Причём rpm не может отследить их все, они в пакете не написаны, там только непосредственные зависимости. Но со своей задачей rpm справляется.

Поэтому для решения этих задач используется диспетчер пакетов. В альте используется apt? Advanced Package Tool. Он взят из дебиавна, в котором ещё и свой формат пакетов --- dpkg. Он был достаточно универсален, чтобы после нескольких ударов кувалдой он начинал использовать rpm. Причём его писали такие хакеры, что можно и кувалду сломать.

Мы уже описали ситуацию, пр и которой установщик пасует. Что же ... .

• Пользователь совершенно не обязан указывать версию пакета. Откула apt узает версию пакета? В отличие от установщикА, диспетчер пакета работает с хранилищами пакетов. Он знает, где лежат все пакеты, которые я могу захотеть установить. Хранилищ может быть несколько. Диспетчер кеширует индексы. Соответственно, есть две утилиты --- apt-get , который работает с хранилищами непосредственно, и apt-cache, котрый работает с кэшем.

Соответственно, диспетчер делает то, что не может установщик: строит дерево зависимостей, получает необходимые и запускает их установку.

• apt-get install <имя пакета> --- установка пакета
• apt-get remove <имя пакета> --- удаление пакета
• apt-get update --- обновление индексов

Таким образом, на долю утилиты apt ложится обновление из изменяющегося хранилища.

• apt-cache search --- ищет имтроку в именах пакетов, их описаниях и файлах

У обоих команд (rpm и apt) есть дикое количество ключей.

Кроме апта, есть есть графические утилиты для работы с пакетами.

Любая команда по работе с системой должна выполняться с правами суперпользвователя.

Ровно одна задача --- модификация самой системы --- делается с правами суперпользователя.

[править] Принципы

• Всё представляется в виде файлов, в файлах находится человекочитаемый, человекомодифицируемый кэш. Одним из следствием этого представления являетсяследующее: вы берёте все файлы, собюираете архив, переносите и оно работает на другой машине. Более того, есть cf(?) engine, котрый позволяет раздавать настройки централизованно.
• Практически любой инрструмент прогр. окруж., который предп. исп. пользователем и который достаточно сложный, хранит конфигурацию в /etc. Структура конф. файла может быть разнообразной. Кроме того, утилиты пользовательские имеют обыкновение хранить свои файлы в домашнем каталоге.
• За исключением /tmp, писать можно разве что в домашний каталог (/home/loginname), где можно делать что угодно. И в нём всё пользовательское. Второе --- cd переводит в домашний каталог. pwd для шелло по умолчанию --- домашний каталог. Забавное следствие этого дела --- для того, чтобы утащить все свои файлы, достаточно утащить его. Имнно сюда, в этот катлог, большинство утилит складывают свои конфиги. Причём складывают именно пользовательские настройки.
• Имена файлов, начинающиеся с точки, считаются скрытыми. Это значит, что они не включаются в общий список файлов, если этого не указать явно.
• Для того, чтобы утащить только настройи, нужно утащить все файлы, начинающиеся с точки.
• Что может относиться не к конф. файлам: $HOME/bin. Если эта штука в path, то оттуда точно можно запускать, ес другой стороны, писать туда можно, следовательно это те программы/скрипты, котрыми вы пользуетесь в работе.

Как это понятие окружения --- всё --- файл --- помогает сохранять окружение: делаете архив и переносите.

Последний финт ушами: технология совместной разработки программ. Мы знаем, что любой приличный свободный проект разрабатывается не одним человеком. Это, а также дисциплина разработки свободных программ диктует в качестве строгой нормы исп. средств совм. разработки, которое поддерживает дерево файлов, позволяет изменять его.

• cvs. Concurrent Version System. Одно из старейших средств.
• darcs
• git

Где тут совместня разработка?

• У меня есть инстр. совм. разр., сост. их хранилища и механизма скачивания и закачивания изм. версии. Это прямая параллель с конф. файлами, которые скачиваются при логине, возм. впроцессе изм., и при логауте оно закачивается обратно на сервер. Казалось бы, она решена, но на самом деле не решена. Каждый линуксоид работает одновременно на неск. машинах. Теперь предст. ситуацию, когда изменили конфиг на рабочей машине, а потом убили X-server, вышли нестандартным образом. В результате сначал закоммитилась изм. версия, а потом неизменённая. Вот тут-то и вспоминаем, что у нас средства совм. разработки. Поэтому тот, кто сделал изм., тот и прав. После того, как лектор в третий раз убил репозиторий, он решил перейти на системы, которые синхронизируют патчи. Пожтому лектор перешёл на darcs. Но он при удачном стечении обстоятельств может вычислять патч 10 минут. В этто момент в альте появился гит, он начал предоставлять бесплатный гит-хостинг.