• На данный момент для координирования работ используется макрос ExtractModules (тот же, что и в PspoModules). Возможно, впоследствии будет написано нечто более специфичное для данных работ.

• Над каждым модулем работает один расшифровщик (указывается первым в списке сопровождающих модуль),один переводчик (указывается вторым в списке) и минимум один технический редактор (тот, кто вычитывает, указывается третьим в списке).
• Разбивка прогресса по процентам:

  0%	Сырой конспект
  20%	Дешифрованный конспект
  50%	Конспект, переведённый на русский язык
  70%	Вычитанный конспект
  90%	Иллюстрирование, расстановка ссылок, перенос в модули
  100%	Результат работ над частью лекций проверен FrBrGeorge

• Как только Вы считаете, что закончили свою часть работы, просьба установить соответствующее количество процентов
• Промежуточное количество процентов в промежуточных сохранениях приветствуется

Пожелания к ролям

• Расшифровка — по возможности полное восстановление структуры и смысла лекции по конспектам и (если есть необходимость) по аудиозаписям. в эту задачу входит расстановка имеющихся иллюстраций (typescript, konsole.log, снимки экрана)

• Перевод на русский — выравнивание стилистки и корректировка владения русским языком. Просьба не очень самовыражаться (чтобы не создавать стилистического разнобоя)

• Вычитка — проверка получившегося текста на (1) соответствие действительности (2) доходчивость (в том числе на предмет нехватки иллюстраций)

CategoryPolicy

Не проговорили про серверный софт. У лектора спрашивали про то, какие программы для фаерволла есть под линукс. Раскрытие этого момента тоже не помешало привернуть. Ибо тут линукс для новенького, а сервер для новенького это ...

Установка софта под Линукс

Достаточно простая тема. В прошлый раз было порядка трёх лекций про это. Лектор хочет это сделать ещё и потому, потому что считает, что открыл некоторый инвариант, которого нет в Линуксе.

Откуда вообще берутся программы под Линукс. Надо дать достаточно точный ответ, ибо обычно это звучит как «лежат на диске» или «скачал из сети». У такого подхода есть неприятное побочное свойство: есть какая-то ОС, вы скачиваете программный продукт из неизвестного места. Вот эти ребята, авторы программного продукта, в курсе, что у вас на машине? Как они могут обеспечить работоспособность программы в вашем окружении? Отсюда растёт проблема...

Дистрибутив и репозиторий

Засунули диск --- установили из диска; нажали кнопку --- скачалось с сайта. Надо понимать, что практически все современные большие дистрибутивы --- подготовленные к использованию программы, взятые из большего дистрибутива. То есть, вот существует большое количество ПО, и часть его лежит в дистрибутиве. Есть большое хранилище СПО, которое содержит кучу всевозможных программных продуктов, пригодных для использования, которым пользуются пользователи дистрибутива.

Чтобы пояснить: есть компания Альт Линукс, которая делает деньги помощью дистр. ALT Linux. Есть ALT Linux Team, и эта тим содержит репозиторий, называемый Сизиф. Этот самый сизиф — конгломерат программных продуктов условно всегда последней версии. Всякий раз, когда какому-то конкретному человеку понадобится программа более свежая или отсутствующая в сизифе, то, если это сознательный член ALT Linux Team, то он её собирает и выкладывает в сизифе. Надо понимать, что эти пакеты оттестированы частично. Понятно, что оно оттестировано только в окружении того, кто это собирал. После обновления видеодрайверов карточки интел, в которой исправлены 160 ошибок, перестала работать карточка на рабочей машине в альте, оказалось, что она неподдерживаемая, но за счёт взаимоуничтожения ошибок,раньше работала. По картинке хорошо видно, что размер этого хранилища больше, чем объём дистрибутива (Сизиф --- третий по размерам после дебиана и федоры). Пользоваться этим на рабочей системе могут только квалифицированные ребята, однако, учитывая особенности команды, это несложно.

Может случиться так, что при обновлении одного продукта другие работать перестанут (до тех пор, пока их не пересоберут или не обновят). Это нестабильное хранилище, то, что там что-то не работает --- обычная ситуация. В какой-то момент Альт Линукс принимает решение выпустить дистрибутив. Как это делают: берётся Сизиф и делается заморозка. Делается замороженная копия, в которой не позволено изменять версию, если только она не содержит исправление критических ошибок. Результатом такой политики заморозки становится то, что большинство программ из числа используемых становятся намного более стабильными. Вот тогда-то компания говорит «всё», что мы можем брать и выбирать нужные нам программы для нужных нам целей, оформлять их нужным образом и таким образом делать из этого программный продукт.

Другие варианты

Лектор специально нарисовал кусочек дистрибутива вне хранилища, поскольку существует часть дистрибутива, которая не входит на полных правах, например, обработанные кувалдой программы (мц, в который вбита поддержка юникода). Эти программы лежат в замороженном дистрибутиве и потом выбрасываются. В некоторых дистрибутивах инсталлятор является несвободным, например в АСП, связанная с инсталляцией под виндовз. Компании выгодно держать одну ветку, из которой нарезаются разные дистрибутивы. Если ставить программу из дистрибутива, то ничего нештатного в идеале не может произойти.

• Если ставите программу из ветки, то возможны мелкие неприятности.
• Если есть ПО в сизифе и нет в ветке.
• Собрать самому. Может практически любой компьютерно-грамотный, благо примеров много.
• Бинарник. Последний вариант. Ибо непонятно, как он собран, и есть много причин, по которым он может не заработать.

О каталогах

Лектор не знает, говорил ли он про это, но он ещё раз говорит: в Линуксе достаточно аккуратно проделано разделение прав доступа, и без ведома пользователя к ним другой пользователь не имеет доступа. Тем не менее, процессы под рутом чихать хотели на них. И установка делается под рутом. Для простого пользователя на запись открыты только ~ и /tmp, а некоторые закрыты и на чтение, и установку специфического ПО, кроме как в свой каталог, пользователь не может, а рут может.

В линуксе существует строгая иерархия каталогов (FHS), которая описывает какие есть каталоги, и для чего они нужны. Почитайте FHS, почитайте учебник лектора. Существует 4 места для ПО, существует 2 каталога для разделяемых библиотек, существует 1 каталог для документации, и так далее. Каждая программа, состоящая из многих файлов, раскидывает их по дереву.

Типичная структура:

• /usr/bin/prog
• /usr/share/doc/proc/README
• /usr/share/man/1/prog.tgz

И это всё один программный продукт.

Пакет

Теперь сведём всё это воедино и выстроим понятие пакета. Вводим понятие пакета:

Пакет --- файл, содержащий всё необходимое для установки и удаления программного продукта.

• Пакет --- архив. В отличие от системы, в которой нет иерархии каталогов, этот архив имеет понятную структуру. Это архив вполне известной структуры. Достаточно ли просто его разархивировать? Нет.
• Регистрация в системе.
• Первичная настройка.

Этого на самом деле недостаточно. А в случае, если эти файлы уже есть? Конфликт.

Разделяемая библиотека.

• При использовании библиотек программы занимают мало место
• Библиотека загружается в память один раз
• Для такой штуки не нужно даже своп заводить --- свопом этого файла будет файл на диске.
• Если библиотека имеет ошибку, то её быстро найдут
• Зависимости. Разделяемые библиотеки в пакет не входят. Каждая группа библиотек лежит в отдельном пакете. И перед установкой программного продукта нужно установить все его зависимости. Палка о двух концах. С одной стороны, очень упрощает разработку; усложняет оно порядок установки программ --- необходимо скачать всё дерево (ацикличесикй орграф) зависимостей. В любом дистре линукс существует две программы --- программа-установщик и менеджер пакетов. В частности, в качестве установщика используется rpm, а в качестве установщика --- apt. Очень важная штука для понимания того, что такое дистрибутив.

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

• Конфликты. Пакеты называются одинаково (vi), но файлы разные. Есть метод --- альтернатива --- который позволяет избежать конфликтов. Будет vi, но будет ещё файл vi.original, и там будет несколько файлов, и за имя vi побеждает тот, у кого вес больше.

Кроме этого существуют непрямые зависимости. Может быть такая ситуация, что для работы вашего продукта другой программный продукт не нужен. Например, для почтового вебсервера нужен почтовый сервер --- нет, но это ситуация редкая. Поэтому установка почтового сервера требовать или нет? По-хорошему надо, но это рекомендованный пакет. <i>(vvk: веб-интерфейс может быть размещён на отдельном хосте, ovz-контейнере, etc, так что в данном случае такая зависимость скорее вредна чем полезна ;))</i> По принципу нестрогих зависимостей была устроена документация в альте.

В рамках дистрибутива всё будет хорошо.

Когда вы обращаетесь к хранилищу, может случиться ситуация, что уже все поменялось. В этом случае можно попробовать следующий способ: помимо rpm есть src.rpm, в котором всё необходимое для сборки программного продукта. Можно скачать src.rpm и пересобрать его в своём окружении. Всё сводитя к выполнению новых команд:

• Скачать src.rpm
• Собрать. Образуется бинарный rpm
• Бинарный rpm встанет со всеми зависимости

Рассказ про us army lab

Важная вещь: откуда берутся пакеты. Существует хранилище (указанное в /etc/apt/sources.list), которое в сумме даёт граф зависимостей, их можно как-то сравнивать и производить обновления.

Против чужих пакетов в репозитории:

• Чужие пакеты --- может перестать работать обновление
• Сборка. Если хотите активно пользоваться программой, то скачали, conf-make-make install, потом ещё раз скачали... В результате, 16 версий библиотеки, удалить их нельзя, потому что может их ещё кто-то использовать, начинают находиться старые библиотеки вместо новых. Поэтому надо класть в сизиф собранные пакты.