Редактирование: UNИX, осень 2007, 10 лекция (от 07 декабря)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
Текущая версия | Ваш текст | ||
Строка 6: | Строка 6: | ||
Лектор обнаружил, что в шелле нет поддержки семафоров и прочих способов межпроцессного взаимодействия. Лектор почитал статью и выяснил, что в 2004 году написали реализацию семафоров на шелле, а потом и очередь. | Лектор обнаружил, что в шелле нет поддержки семафоров и прочих способов межпроцессного взаимодействия. Лектор почитал статью и выяснил, что в 2004 году написали реализацию семафоров на шелле, а потом и очередь. | ||
- | + | Тема настройки | |
- | + | ||
- | Установщик --- штука, которая может установить/удалить пакет, проверить его, посмотреть | + | Для начала вспомним про установку программ. Единицей ПО считается пакет. Пает обьладает массой свойств --- это не только распаковка, но и регистрация в систиеме, запуск некоотрых сценариев при установке/удалении. Пакеты друг от друга зависят по причине того, что раздлеяеме библиотеки нужны нескольким пакетам. Существует понятие конфликт, и он разрешается (для разрешения конфликта достаточно авторам пакетам договориться и переименовать конфликтующие файлы и использовать механизм альтернатив). Работой с одним пакетом заниимается установщик. Установщик --- штука, которая может установить/удалить пакет, проверить его, посмотреть дифф, проверить зависимости(и не удалять пакет, если он ещё зависимый/не устанавливать, если есть неразрешённые зависимости). По традиции, установщик также используется для сборки пакета. Но это нас волновать не должно, а волновать должны две вещи: установщик работает с одним файлом, а для реальной работы надо использовать диспетчер пакетов (в альте апт), который работает сразу с хранилищами пакетов, в которых пакетов много и которые могут работать где угодно. В итоге задача диспетчера состоит в построении графа зависимостей, выяснить, что есть, докачать, что нет и установить скачанные пакеты. Поскольку установщик может работаь с разными архивами, можно легко организорвать обновление: в одном из хранилищ обновляются пакеты, и оттуда можно брать новые версии. Установка программ в линукс это такая шгтука, которую лучше делать в рамках репозитория, но можно и по-другому, и способов три: |
- | + | ||
- | Установка программ в линукс это такая | + | |
* Собрать собственными силами | * Собрать собственными силами | ||
- | * Попробовать взять чужой пакет. | + | * Попробовать взять чужой пакет. Мождет оказаться, что пакет хочет те же библиотеки, но с другими именами |
- | * Скачать какие-то бинарники, куда-то положить, как-то запустить. Тоже не | + | * Скачать какие-то бинарники, куда-то положить, как-то запустить. Тоже не овчень хороший вариант |
- | + | Единственное, что можно добавить к прошлой лекции: как распоряжаться этими бинарниками. Очень не рекомендуется пользоваться так называемыми инсталляторами. В самом лучшем случае он сделает следующее: в /opt/ (в котором ставятся программы вне дистрибутива) будет /opt/(program name)/{bin, lib, ...} Единственная проблема перед разработчиками --- заставить запускаться бинарник оттуда. Поэтому даже в этом случае он нагадит в /usr/bin/ пускачём (это плохо тем, что в стандартом каталоге будет файл, не принадлежащий ни одному пакету). Чуть менее хороший вариант --- /usr/local/{bin, lib, ...}. /usr/local/ --- то, что живёт только на вашей системе и должно быть сохранено после убиения системы и установки новой. Чем это плохо --- конфликт имён. Чем это лучше --- /usr/local/ обычно есть в PATH и установщик больше никуда лезть не будет. И то, и другое должно происходить от имени рута, и этим лектору ещё больше не нравится идея использовать установщики. При этом никто не гарантирует, что в ваши стандартные места не наложит барахла. Например, кроссовер офис любит в usr/bin любит складывать симлинки на виндовые программы, которые сам же и запускает. Ещё есть ~/bin и ~/.local, но отнюдь не все программы смогут запуститься. | |
- | Единственное, что можно добавить к прошлой лекции: как распоряжаться этими бинарниками. Очень не рекомендуется пользоваться так называемыми инсталляторами. В самом лучшем случае он сделает следующее: в /opt/ (в котором ставятся программы вне дистрибутива) будет /opt/(program name)/{bin, lib, ...} Единственная проблема перед разработчиками --- заставить запускаться бинарник оттуда. Поэтому даже в этом случае он нагадит в /usr/bin/ пускачём (это плохо тем, что в стандартом каталоге будет файл, не принадлежащий ни одному пакету). | + | |
- | + | Тперь развилка: слвсем пользовательская --- как дальше жить с этим линуксом, поскольку существуют приёмы работы, которые сущесвуют для того, чтобы создать себе комофорт, например, вебсёрфинг. Другая тема --- настрока. Похоже, что лектор будет говорить про настройку, а в следующий раз будут маленькие хитрости. | |
- | + | Настройка | |
- | + | Это довольно болезненное место, одно из мест, по части которых имеются притензии к Линукс-системам. Лектору непонятны претензии, но непонятно, откуда они растут. | |
- | + | В начале мы договорились, что граф. оболочка это не Линукс. Тем не менее, ... Растёт это понятно откуда: человек привык выдирать «панель управления», и там есть «всё», что можно настроить. Понятно, что там явно не всёЮ и если бы показали всё, то он впал бы в подавленное состояние духа. Что пользователь видитЮ, когда тыкает в настройки: он видит графического плана утилиты, которые что-то настраивают. Они бывают 4 сортов: | |
- | + | ||
- | В начале мы договорились, что граф. оболочка это не Линукс. Тем не менее, ... Растёт это понятно откуда: человек привык | + | |
* Настройка каких-то приложений (KDE Control Center, который в первую очередь настраивает KDE). Наиболее правильный тип. Если само приложение графическое, то и настройщик графический. В большинстве из них есть пункт настройка, но есть и настройщики в виде отдельной программы. | * Настройка каких-то приложений (KDE Control Center, который в первую очередь настраивает KDE). Наиболее правильный тип. Если само приложение графическое, то и настройщик графический. В большинстве из них есть пункт настройка, но есть и настройщики в виде отдельной программы. | ||
- | * Более шаткая штука --- когда настройщики того же КДЕ начинают лезть в систему. Пример: | + | * Более шаткая штука --- когда настройщики того же КДЕ начинают лезть в систему. Пример: ялвяется ли системной настройка частоты обновления и разрешения экрана. Казалось бы, нет, с другой стороны эта штука точно была в ведомости админа, так как необзодима правка конфига граф. подсистемы. В том же KDE Control Center или гноме можно увидеть ручки, которые лезут в систему. «Системы в рамках рабочего стола». То же самое --- работа со звуком. Идея в следующем --- ребята, которые делают рабочий стол говорят, что разрешение --- дело рабочего стола, поэтому должны быть ручки, если же нет, то нет. Поэтому не факт, что ручки из граф. подсистемы обязаны заработать. |
- | * Настройка некоторых специальных служб, которые имеют собственный графический/веб интерфейс. Есть как минимум две таких службы --- купс и самба. Почему отдельной строкой --- потому что конфигуратор к таким мощным системам разработчик дистрибутива просто не будет | + | * Настройка некоторых специальных служб, которые имеют собственный графический/веб интерфейс. Есть как минимум две таких службы --- купс и самба. Почему отдельной строкой --- потому что конфигуратор к таким мощным системам разработчик дистрибутива просто не будет |
- | * Настройка системы --- дистриб. Если создатели дистр. решили облегчить жизнь | + | * Настройка системы --- дистриб. Если создатели дистр. решили облегчить жизнь пользхователю, который объявляется системным (альтератор в альте, в сусе яст). Имеет смысл обратить внимание на этот конфигуратор, поскольку его точно будут тестировать. Правда,можно обнарудить, что в этих конф. не так много всего и есть. Но это связано со спецификой дистрибутива. |
* Существуют специальные стэндэлон настроечные среды (вебмин), которые тоже предназначены для того же самого. Может быть, но у лектора есть твёрдое ощущение, что необходимость в таких конфигураторах отпадает. Проблема в том, что это очень сложно. Вплоть до того, что выясниться, точ чем универсальнее тот инструмент, который управляется всем и вся, тем меньше пересечение. /* рассказ про патчинг купса и NU_IZVRAT */. То есть, они либо становятся дистрибутивоспецифичными, либо задачеспецифичными. | * Существуют специальные стэндэлон настроечные среды (вебмин), которые тоже предназначены для того же самого. Может быть, но у лектора есть твёрдое ощущение, что необходимость в таких конфигураторах отпадает. Проблема в том, что это очень сложно. Вплоть до того, что выясниться, точ чем универсальнее тот инструмент, который управляется всем и вся, тем меньше пересечение. /* рассказ про патчинг купса и NU_IZVRAT */. То есть, они либо становятся дистрибутивоспецифичными, либо задачеспецифичными. | ||
- | Существует ещё ряд вещей, | + | Существует ещё ряд вещей, нарпимер, вебдвижки, которые опять же настраиваются веб-мордой. |
Вот это всё не может равняться всему тому, что можно настраивать. | Вот это всё не может равняться всему тому, что можно настраивать. | ||
Строка 41: | Строка 35: | ||
Проблемы: | Проблемы: | ||
- | * Пространство имён. Если мы | + | * Пространство имён. Если мы хотис настраивать всю систему целиком, то мы должны создать такой способ именования этих настроек, чтобы в нём было легко ориентироваться. Вот регистри --- плохой пример организации. |
- | * Должны быть внутри этого места, где мы держим настройки, должен быть гибкий формат представления. Чем опять же плох реджистри --- если мы | + | * Должны быть внутри этого места, где мы держим настройки, должен быть гибкий формат представления. Чем опять же плох реджистри --- если мы гворим, что у нас древесная труктура, то сразу вычёркиваем два класса сущностей --- организация в виде графа (tags), вотрое --- программы; они тоже могут быть штуками, которые управляют системой. То есть в нашем пространстве имён должны быть данные любые |
* Удобный инструментарий для чтения и модификации. Лектор сошлётся на свою идею более чем десятилетней давности --- существует такой критерий --- человекоприемлемости: кусок данных можно назвать пригодным, если его можно написать с нуля. | * Удобный инструментарий для чтения и модификации. Лектор сошлётся на свою идею более чем десятилетней давности --- существует такой критерий --- человекоприемлемости: кусок данных можно назвать пригодным, если его можно написать с нуля. | ||
- | + | ||
- | + | какая ситуация в линуксе: до сих пор это решается старым юниксовым способом --- любой файл --- человекочитаемый текст. Один из вопросов, который возник в процессе диалога с гуру --- что такое плоский текст. Когда лектор говорит про текстовый файл, то он имеет в виду файл в виде плоского текста. Если текст --- некий поток символов, тол плоский текст хранит только информаци., а размеченный текст хранит метаинформацию. То есть, когда вы видете плоский текст, то вы видите то, что должны видеть, а размеченный текст можно показывать в виде плоского текста и в формате представления. Так вот. Когда лектор говорит, что любой файл является текстовым, то это значит, что он всегда доступен как текст плоский, то есть его можно редактировать текстовым редактором. | |
Теперь попробуем описать, как это выглядит: | Теперь попробуем описать, как это выглядит: | ||
* Пространство имён --- файловая система. Зачем множить сущности (дерево), если дерево уже есть. В /etc/ лежат файлы, необходимые для настройки остальной части системы | * Пространство имён --- файловая система. Зачем множить сущности (дерево), если дерево уже есть. В /etc/ лежат файлы, необходимые для настройки остальной части системы | ||
** Каждый файл принадлежит пакету, и названия в etc соответствуют названиям пакетов. Это способ локализации | ** Каждый файл принадлежит пакету, и названия в etc соответствуют названиям пакетов. Это способ локализации | ||
- | * Гибкость представления --- пишите что хотите. За это упрекают линукс. Что-то плоско, что | + | * Гибкость представления --- пишите что хотите. За это упрекают линукс. Что-то плоско, что дреоввидно, что-то --- прграмма на шелле. Но это нормально |
- | * Чтение и модификация. С одной стороны, есть гуёвые программы. В каком-то смысле они удобные. Но хорошо граф. интерфейс делает настройку граф. интерфейса и стандартных типовых задач. А каковы должны быть инструменты, которые бы позволили читать и изменять практически любой конфиг файл? Поскольку мы договорились, что конфиги представляются в виде текста, то у нас есть способ работы с текстом --- текстовый редактор, в случае, если нет задач автоматизации. Но редактор текста должен обладать не совсем таким набором возможностей, каким должен обладать редактор конфигурационных файлов. При редактировании литературного текста обычно необходимо проверять орфографию, писать и писать, и потом в конце переставить пару абзацев. Когда работаете с конфиг-файлов, элементы разметки или другие синт. единицы служат объектами оперирования, то есть, вы находите секцию, в которой хранится свойство, и изменяете это свойство. Поэтому редактор, | + | * Чтение и модификация. С одной стороны, есть гуёвые программы. В каком-то смысле они удобные. Но хорошо граф. интерфейс делает настройку граф. интерфейса и стандартных типовых задач. А каковы должны быть инструменты, которые бы позволили читать и изменять практически любой конфиг файл? Поскольку мы договорились, что конфиги представляются в виде текста, то у нас есть способ работы с текстом --- текстовый редактор, в случае, если нет задач автоматизации. Но редактор текста должен обладать не совсем таким набором возможностей, каким должен обладать редактор конфигурационных файлов. При редактировании литературного текста обычно необходимо проверять орфографию, писать и писать, и потом в конце переставить пару абзацев. Когда работаете с конфиг-файлов, элементы разметки или другие синт. единицы служат объектами оперирования, то есть, вы находите секцию, в которой хранится свойство, и изменяете это свойство. Поэтому редактор, котрый редактирует конфиг, должен быстро производлить поиск, модификацию и модификацию автоматическую. типичный пример: заменить имя хоста. Почему бы это не оформить в виде парсера? Некоторые задачи можно решить вручную, но некоторые задачи можно решить машиной, и лучше, чтобы таких задач было как можно больше. И в таких случаях нужны процессоры обработки текста. Поэтому в линуксе есть много программ, которые работают с ФС, с пакетом, котрые занимаются с плоской обработкой текста. Именно эти программы и являются инструментом, которые позволяют что угодно делать с настройкой. |
vim, emacs. Сначала надо научиться ими пользоваться, а потом им пользоваться. | vim, emacs. Сначала надо научиться ими пользоваться, а потом им пользоваться. | ||
- | Если нужно | + | Если нужно рабоатать сразу,то есть nano, mc, kate, evim. |
21 будет экзамен. | 21 будет экзамен. |