Редактирование: UNИX, осень 2007, 10 лекция (от 07 декабря)

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

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

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

[[UNИX, осень 2007, 09 лекция (от 30 ноября)|Предыдущая лекция]] | [[UNИX, осень 2007, 11 лекция (от 14 декабря)|Следующая лекция]]

'''Официальная страница''': <br />
'''Аудиовариант''': [http://esyr.org/lections/audio/uneex_2007_winter/Linux_07_12_07.wav]

Лектор обнаружил, что в шелле нет поддержки семафоров и прочих способов межпроцессного взаимодействия. Лектор почитал статью и выяснил, что в 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), второе --- программы; они тоже могут быть штуками, которые управляют системой. То есть в нашем пространстве имён должны быть данные любые
* Удобный инструментарий для чтения и модификации. Лектор сошлётся на свою идею более чем десятилетней давности --- существует такой критерий --- человекоприемлемости: кусок данных можно назвать пригодным, если его можно написать с нуля.
=== Текстовые конфиги ===
Какая ситуация в линуксе: до сих пор это решается старым юниксовым способом --- любой файл --- человекочитаемый текст. Один из вопросов, который возник в процессе диалога с гуру --- что такое плоский текст. Когда лектор говорит про текстовый файл, то он имеет в виду файл в виде плоского текста. Если текст --- некий поток символов, тол плоский текст хранит только информацию, а размеченный текст хранит метаинформацию. То есть, когда вы видете плоский текст, то вы видите то, что должны видеть, а размеченный текст можно показывать в виде плоского текста и в формате представления. Так вот. Когда лектор говорит, что любой файл является текстовым, то это значит, что он всегда доступен как текст плоский, то есть его можно редактировать текстовым редактором.

Теперь попробуем описать, как это выглядит:
* Пространство имён --- файловая система. Зачем множить сущности (дерево), если дерево уже есть. В /etc/ лежат файлы, необходимые для настройки остальной части системы
** Каждый файл принадлежит пакету, и названия в etc соответствуют названиям пакетов. Это способ локализации
* Гибкость представления --- пишите что хотите. За это упрекают линукс. Что-то плоско, что древовидно, что-то --- программа на шелле. Но это нормально
* Чтение и модификация. С одной стороны, есть гуёвые программы. В каком-то смысле они удобные. Но хорошо граф. интерфейс делает настройку граф. интерфейса и стандартных типовых задач. А каковы должны быть инструменты, которые бы позволили читать и изменять практически любой конфиг файл? Поскольку мы договорились, что конфиги представляются в виде текста, то у нас есть способ работы с текстом --- текстовый редактор, в случае, если нет задач автоматизации. Но редактор текста должен обладать не совсем таким набором возможностей, каким должен обладать редактор конфигурационных файлов. При редактировании литературного текста обычно необходимо проверять орфографию, писать и писать, и потом в конце переставить пару абзацев. Когда работаете с конфиг-файлов, элементы разметки или другие синт. единицы служат объектами оперирования, то есть, вы находите секцию, в которой хранится свойство, и изменяете это свойство. Поэтому редактор, который редактирует конфиг, должен быстро производить поиск, модификацию и модификацию автоматическую. типичный пример: заменить имя хоста. Почему бы это не оформить в виде парсера? Некоторые задачи можно решить вручную, но некоторые задачи можно решить машиной, и лучше, чтобы таких задач было как можно больше. И в таких случаях нужны процессоры обработки текста. Поэтому в линуксе есть много программ, которые работают с ФС, с пакетом, которые занимаются с плоской обработкой текста. Именно эти программы и являются инструментом, которые позволяют что угодно делать с настройкой.

vim, emacs. Сначала надо научиться ими пользоваться, а потом им пользоваться.

Если нужно работать сразу,то есть nano, mc, kate, evim.

21 будет экзамен.

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.us/wiki/UN%D0%98X%2C_%D0%BE%D1%81%D0%B5%D0%BD%D1%8C_2007%2C_10_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_07_%D0%B4%D0%B5%D0%BA%D0%B0%D0%B1%D1%80%D1%8F%29

Редактирование: UNИX, осень 2007, 10 лекция (от 07 декабря)

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

Просмотры

Личные инструменты

Навигация

инструменты

Разделы

Спецкурсы

9 семестр

7 семестр

5 семестр

3 семестр

Поиск

Инструменты

@@ Строка 2: / Строка 2: @@
 '''Официальная страница''': <br />
-'''Аудиовариант''': http://esyr.org/lections/audio/uneex_2007_winter/Linux_07_12_07.wav
+'''Аудиовариант''': [http://esyr.org/lections/audio/uneex_2007_winter/Linux_07_12_07.wav]
 Лектор обнаружил, что в шелле нет поддержки семафоров и прочих способов межпроцессного взаимодействия. Лектор почитал статью и выяснил, что в 2004 году написали реализацию семафоров на шелле, а потом и очередь.