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

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

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

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

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

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

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

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

CategoryPolicy

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

Установщик пакетов

Для начала вспомним про установку программ. Единицей ПО считается пакет. Пакет обладает массой свойств --- это не только распаковка, но и регистрация в системе, запуск некоторых сценариев при установке/удалении. Пакеты друг от друга зависят по причине того, что разделяемые библиотеки нужны нескольким пакетам. Существует понятие конфликта, и конфликты необходимо разрешать (для этого авторам пакетов достаточно договориться и переименовать конфликтующие файлы, и использовать механизм альтернатив). Работой с одним пакетом занимается установщик.

Установщик --- штука, которая может установить/удалить пакет, проверить его, посмотреть diff, проверить зависимости (и не удалять пакет, если он ещё зависимый/не устанавливать, если есть неразрешённые зависимости). По традиции, установщик также используется для сборки пакета. Но это нас волновать не должно, а волновать должны две вещи: установщик работает с одним файлом, а для реальной работы надо использовать диспетчер пакетов (в альте апт), который работает сразу с хранилищами пакетов, в которых пакетов много и которые могут работать где угодно. В итоге задача диспетчера состоит в построении графа зависимостей, выяснить, что есть, докачать, что нет и установить скачанные пакеты. Поскольку установщик может работать с разными архивами, можно легко организовать обновление: в одном из хранилищ обновляются пакеты, и оттуда можно брать новые версии.

Установка программ в линукс это такая штука, которую лучше делать в рамках репозитория, но можно и по-другому, и способов три: * Собрать собственными силами * Попробовать взять чужой пакет. Может оказаться, что пакет хочет те же библиотеки, но с другими именами * Скачать какие-то бинарники, куда-то положить, как-то запустить. Тоже не очень хороший вариант

О каталогах

Единственное, что можно добавить к прошлой лекции: как распоряжаться этими бинарниками. Очень не рекомендуется пользоваться так называемыми инсталляторами. В самом лучшем случае он сделает следующее: в /opt/ (в котором ставятся программы вне дистрибутива) будет /opt/(program name)/{bin, lib, ...} Единственная проблема перед разработчиками --- заставить запускаться бинарник оттуда. Поэтому даже в этом случае он нагадит в /usr/bin/ пускачём (это плохо тем, что в стандартом каталоге будет файл, не принадлежащий ни одному пакету).

Чуть менее хороший вариант --- /usr/local/{bin, lib, ...}. /usr/local/ --- то, что живёт только на вашей системе и должно быть сохранено после убиения системы и установки новой. Чем это плохо --- конфликт имён. Чем это лучше --- /usr/local/ обычно есть в PATH и установщик больше никуда лезть не будет. И то, и другое должно происходить от имени рута, и этим лектору ещё больше не нравится идея использовать установщики. При этом никто не гарантирует, что в ваши стандартные места не наложит барахла. Например, кроссовер офис любит в usr/bin любит складывать симлинки на виндовые программы, которые сам же и запускает. Ещё есть ~/bin и ~/.local, но отнюдь не все программы смогут запуститься.

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

Это довольно болезненное место, одно из мест, по части которых имеются притензии к Линукс-системам. Лектору непонятны претензии, но понятно, откуда они растут.

В начале мы договорились, что граф. оболочка это не Линукс. Тем не менее, ... Растёт это понятно откуда: человек привык выбирать «панель управления», и там есть «всё», что можно настроить. Понятно, что там явно не всё и если бы показали всё, то он впал бы в подавленное состояние духа. Что пользователь видит, когда тыкает в настройки: он видит графического плана утилиты, которые что-то настраивают. Они бывают 4 сортов:

• Настройка каких-то приложений (KDE Control Center, который в первую очередь настраивает KDE). Наиболее правильный тип. Если само приложение графическое, то и настройщик графический. В большинстве из них есть пункт настройка, но есть и настройщики в виде отдельной программы.
• Более шаткая штука --- когда настройщики того же КДЕ начинают лезть в систему. Пример: является ли системной настройка частоты обновления и разрешения экрана. Казалось бы, нет, с другой стороны эта штука точно была в ведомости админа, так как необходима правка конфига графической подсистемы. В том же KDE Control Center или гноме можно увидеть ручки, которые лезут в систему. «Системы в рамках рабочего стола». То же самое --- работа со звуком. Идея в следующем --- ребята, которые делают рабочий стол говорят, что разрешение --- дело рабочего стола, поэтому должны быть ручки, если же нет, то нет. Поэтому не факт, что ручки из графической подсистемы обязаны заработать.
• Настройка некоторых специальных служб, которые имеют собственный графический/веб интерфейс. Есть как минимум две таких службы --- купс и самба. Почему отдельной строкой --- потому что конфигуратор к таким мощным системам разработчик дистрибутива просто не будет ...?
• Настройка системы --- дистриб. Если создатели дистр. решили облегчить жизнь пользователю, который объявляется системным (альтератор в альте, в сусе яст). Имеет смысл обратить внимание на этот конфигуратор, поскольку его точно будут тестировать. Правда, можно обнаружить, что в этих конф. не так много всего и есть. Но это связано со спецификой дистрибутива.

• Существуют специальные стэндэлон настроечные среды (вебмин), которые тоже предназначены для того же самого. Может быть, но у лектора есть твёрдое ощущение, что необходимость в таких конфигураторах отпадает. Проблема в том, что это очень сложно. Вплоть до того, что выясниться, точ чем универсальнее тот инструмент, который управляется всем и вся, тем меньше пересечение. рассказ про патчинг купса и NU_IZVRAT */. То есть, они либо становятся дистрибутивоспецифичными, либо задачеспецифичными.

Существует ещё ряд вещей, например, вебдвижки, которые опять же настраиваются веб-мордой.

Вот это всё не может равняться всему тому, что можно настраивать.

Дело в том, что: вот такой совокупный конфиг непригоден к тому, что в нём копаться. Идея в том, чтобы организовать пространство управления так чтобы понятно, что есть.

Проблемы:

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

Проблема хранения и редактирования конфигурации в ОС Линукс до сих пор это решается старым, проверенным в unix-системах, способом: любой файл настроек --- человекочитаемый текст. Один из вопросов, который возникает в процессе диалога с гуру --- а что такое плоский текст? Когда говорят про текстовый файл, то имеет в виду файл в виде плоского текста (англ. plain text). Если текст --- некий поток символов, то плоский текст хранит только собственно информацию, а размеченный текст хранит и некоторую метаинформацию о, например, их внешнем виде. Таким образом, когда вы видете содержимое плоского текстового файла, то вы видите именно то, что должны видеть. Размеченный же текст можно показывать в виде плоского текста и в формате представления. Когда говорят, что любой файл является текстовым, то это значит, что он всегда доступен как текст плоский, то есть его можно редактировать текстовым редактором.

В качестве отступления напомним, какие в ОС Линукс бывают текстовые редакторы. Все текстовые редакторы можно разделить на:

• классические редакторы (vi, vim, emacs), которые могу работать как в консоли, так и в графическом окружении;
• современные редакторы, требующие графической среды (например, редактор kate для среды KDE);
• простые редакторы для эпизодического использования (например, в ПСПО входит простой редактор mcedit).

Остается напомнить, что программы типа OpenOffice Writer текстовыми редакторами не являются: их принято называть текстовыми процессорами, и работают они с размеченным текстом.

Важным следствием хранения конфигурации в текстовых файлов является возможность использовать стандартный набор утилит для обработки текста, таких как sed, grep , tail, head, echo. Особенно следует здесь отметить утилиту для автоматической замены в файлах sed.

Опишем общие концепции системы настроек в unix-подобных системах.

Пространство имён --- файловая система. Для того, чтобы настройки одной программы не путались с настройками другой, необходимо использовать пространства имён. В нашем случае пространство имён дает файловая система: зачем множить сущности (создавать некоторую древовидную классификацию настрроек), если дерево каталогов уже есть? В каталоге /etc лежат файлы, необходимые для настройки остальной части системы, а пользовательские настройки лежат в каталоге пользователя в файлах и каталогах, имя которых начинается с точки (".", англ. dot files), по-умолчанию пользователю их не видно.

У каждого пакета --- свои файлы конфигурации. В правильном дистрибутиве ОС Линукс Каждый файл принадлежит какому-то одному (и только одному) пакету. Имена большинства подкаталогов в /etc соответствуют названиям пакетов, хотя и далеко не всегда с ними точно совпадают. Последний момент связан с тем, что имена каталогов, например /etc/ssh, обычно одинаковы для различных unix-подобных систем, а вот имена пакетов определеются внутренней политикой ПСПО и обычно совпадабт с названием программы.

Гибкость представления --- пишите, что хотите. Это приводит к разнообразию форматов файлов конфигурации: какие-то конфигурации линейны, какие-то --- древовидны, а какие-то вообще являются сценарием языка shell. За этот "зоопарк" часто упрекают unix-системы, но, с другой стороны, это позволяет выбирать удобный формат под каждую конкретную задачу.

Чтение и модификация с использованием разнообразных инструментов. С одной стороны, для ряда задач есть графические конфигураторы программы. В каком-то смысле они удобные, но обычно они делют настройку графического интерфейса и стандартных типовых задач. А каковы должны быть инструменты, которые бы позволили читать и изменять практически любой конфигурационный файл? Поскольку мы договорились, что конфиги представляются в виде текста, то у нас есть следующие инструменты для работы с текстом:

• текстовый редактор (если нет задачи автоматизации изменений);
• утилиты для обработки текста и работы с файлами и язык программирования shell в случае необходимости или желания автоматизировать работу с конфигурацией;
• интерпретаторы языков программирования (awk, perl, python) для более сложных операций с файлами конфигурации;
• наконец, с текстовыми файлами конфигурации может работать специализированная программа на любом языке программирования (к таким относится, например, графический конфигуратор KDE).

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