Редактирование: UNИX, осень 2007, 10 лекция (от 07 декабря)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
| Текущая версия | Ваш текст | ||
| Строка 6: | Строка 6: | ||
Лектор обнаружил, что в шелле нет поддержки семафоров и прочих способов межпроцессного взаимодействия. Лектор почитал статью и выяснил, что в 2004 году написали реализацию семафоров на шелле, а потом и очередь. | Лектор обнаружил, что в шелле нет поддержки семафоров и прочих способов межпроцессного взаимодействия. Лектор почитал статью и выяснил, что в 2004 году написали реализацию семафоров на шелле, а потом и очередь. | ||
| - | + | Тема настройки | |
| - | + | ||
| - | Установщик --- штука, которая может установить/удалить пакет, проверить его, посмотреть diff, проверить зависимости (и не удалять пакет, если он ещё зависимый/не устанавливать, если есть неразрешённые зависимости). По традиции, установщик также используется для сборки пакета. Но это нас волновать не должно, а волновать должны две вещи: установщик работает с одним файлом, а для реальной работы надо использовать диспетчер пакетов (в альте апт), который работает сразу с хранилищами пакетов, в которых пакетов много и которые могут работать где угодно. В итоге задача диспетчера состоит в построении графа зависимостей, выяснить, что есть, докачать, что нет и установить скачанные пакеты. Поскольку установщик может | + | Для начала вспомним про установку программ. Единицей ПО считается пакет. Пакет обладает массой свойств --- это не только распаковка, но и регистрация в системе, запуск некоторых сценариев при установке/удалении. Пакеты друг от друга зависят по причине того, что разделяемые библиотеки нужны нескольким пакетам. Существует понятие конфликта, и конфликты необходимо разрешать (для этого авторам пакетов достаточно договориться и переименовать конфликтующие файлы, и использовать механизм альтернатив). Работой с одним пакетом занимается установщик. Установщик --- штука, которая может установить/удалить пакет, проверить его, посмотреть diff, проверить зависимости (и не удалять пакет, если он ещё зависимый/не устанавливать, если есть неразрешённые зависимости). По традиции, установщик также используется для сборки пакета. Но это нас волновать не должно, а волновать должны две вещи: установщик работает с одним файлом, а для реальной работы надо использовать диспетчер пакетов (в альте апт), который работает сразу с хранилищами пакетов, в которых пакетов много и которые могут работать где угодно. В итоге задача диспетчера состоит в построении графа зависимостей, выяснить, что есть, докачать, что нет и установить скачанные пакеты. Поскольку установщик может работа с разными архивами, можно легко организовать обновление: в одном из хранилищ обновляются пакеты, и оттуда можно брать новые версии. Установка программ в линукс это такая штука, которую лучше делать в рамках репозитория, но можно и по-другому, и способов три: |
| - | + | ||
| - | Установка программ в линукс это такая штука, которую лучше делать в рамках репозитория, но можно и по-другому, и способов три: | + | |
* Собрать собственными силами | * Собрать собственными силами | ||
| - | * Попробовать взять чужой пакет. | + | * Попробовать взять чужой пакет. Мождет оказаться, что пакет хочет те же библиотеки, но с другими именами |
| - | * Скачать какие-то бинарники, куда-то положить, как-то запустить. Тоже не | + | * Скачать какие-то бинарники, куда-то положить, как-то запустить. Тоже не овчень хороший вариант |
| - | + | Единственное, что можно добавить к прошлой лекции: как распоряжаться этими бинарниками. Очень не рекомендуется пользоваться так называемыми инсталляторами. В самом лучшем случае он сделает следующее: в /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/ пускачём (это плохо тем, что в стандартом каталоге будет файл, не принадлежащий ни одному пакету). | + | |
| - | + | ||
| - | Чуть менее хороший вариант --- /usr/local/{bin, lib, ...}. /usr/local/ --- то, что живёт только на вашей системе и должно быть сохранено после убиения системы и установки новой. Чем это плохо --- конфликт имён. Чем это лучше --- /usr/local/ обычно есть в PATH и установщик больше никуда лезть не будет. И то, и другое должно происходить от имени рута, и этим лектору ещё больше не нравится идея использовать установщики. При этом никто не гарантирует, что в ваши стандартные места не наложит барахла. Например, кроссовер офис любит в usr/bin любит складывать симлинки на виндовые программы, которые сам же и запускает. Ещё есть ~/bin и ~/.local, но отнюдь не все программы смогут запуститься. | + | |
Теперь развилка: совсем пользовательская --- как дальше жить с этим линуксом, поскольку существуют приёмы работы, которые существуют для того, чтобы создать себе комфорт, например, вебсёрфинг. Другая тема --- настрока. Похоже, что лектор будет говорить про настройку, а в следующий раз будут маленькие хитрости. | Теперь развилка: совсем пользовательская --- как дальше жить с этим линуксом, поскольку существуют приёмы работы, которые существуют для того, чтобы создать себе комфорт, например, вебсёрфинг. Другая тема --- настрока. Похоже, что лектор будет говорить про настройку, а в следующий раз будут маленькие хитрости. | ||
| - | + | Настройка | |
| - | Это довольно болезненное место, одно из мест, по части которых имеются притензии к Линукс-системам. Лектору непонятны претензии, но | + | Это довольно болезненное место, одно из мест, по части которых имеются притензии к Линукс-системам. Лектору непонятны претензии, но непонятно, откуда они растут. |
| - | + | ||
| - | В начале мы договорились, что граф. оболочка это не Линукс. Тем не менее, ... Растёт это понятно откуда: человек привык | + | В начале мы договорились, что граф. оболочка это не Линукс. Тем не менее, ... Растёт это понятно откуда: человек привык выдирать «панель управления», и там есть «всё», что можно настроить. Понятно, что там явно не всё и если бы показали всё, то он впал бы в подавленное состояние духа. Что пользователь видит, когда тыкает в настройки: он видит графического плана утилиты, которые что-то настраивают. Они бывают 4 сортов: |
* Настройка каких-то приложений (KDE Control Center, который в первую очередь настраивает KDE). Наиболее правильный тип. Если само приложение графическое, то и настройщик графический. В большинстве из них есть пункт настройка, но есть и настройщики в виде отдельной программы. | * Настройка каких-то приложений (KDE Control Center, который в первую очередь настраивает KDE). Наиболее правильный тип. Если само приложение графическое, то и настройщик графический. В большинстве из них есть пункт настройка, но есть и настройщики в виде отдельной программы. | ||
| - | * Более шаткая штука --- когда настройщики того же КДЕ начинают лезть в систему. Пример: | + | * Более шаткая штука --- когда настройщики того же КДЕ начинают лезть в систему. Пример: ялвяется ли системной настройка частоты обновления и разрешения экрана. Казалось бы, нет, с другой стороны эта штука точно была в ведомости админа, так как необходима правка конфига граф. подсистемы. В том же KDE Control Center или гноме можно увидеть ручки, которые лезут в систему. «Системы в рамках рабочего стола». То же самое --- работа со звуком. Идея в следующем --- ребята, которые делают рабочий стол говорят, что разрешение --- дело рабочего стола, поэтому должны быть ручки, если же нет, то нет. Поэтому не факт, что ручки из граф. подсистемы обязаны заработать. |
| - | * Настройка некоторых специальных служб, которые имеют собственный графический/веб интерфейс. Есть как минимум две таких службы --- купс и самба. Почему отдельной строкой --- потому что конфигуратор к таким мощным системам разработчик дистрибутива просто не будет | + | * Настройка некоторых специальных служб, которые имеют собственный графический/веб интерфейс. Есть как минимум две таких службы --- купс и самба. Почему отдельной строкой --- потому что конфигуратор к таким мощным системам разработчик дистрибутива просто не будет |
* Настройка системы --- дистриб. Если создатели дистр. решили облегчить жизнь пользователю, который объявляется системным (альтератор в альте, в сусе яст). Имеет смысл обратить внимание на этот конфигуратор, поскольку его точно будут тестировать. Правда, можно обнаружить, что в этих конф. не так много всего и есть. Но это связано со спецификой дистрибутива. | * Настройка системы --- дистриб. Если создатели дистр. решили облегчить жизнь пользователю, который объявляется системным (альтератор в альте, в сусе яст). Имеет смысл обратить внимание на этот конфигуратор, поскольку его точно будут тестировать. Правда, можно обнаружить, что в этих конф. не так много всего и есть. Но это связано со спецификой дистрибутива. | ||
* Существуют специальные стэндэлон настроечные среды (вебмин), которые тоже предназначены для того же самого. Может быть, но у лектора есть твёрдое ощущение, что необходимость в таких конфигураторах отпадает. Проблема в том, что это очень сложно. Вплоть до того, что выясниться, точ чем универсальнее тот инструмент, который управляется всем и вся, тем меньше пересечение. /* рассказ про патчинг купса и NU_IZVRAT */. То есть, они либо становятся дистрибутивоспецифичными, либо задачеспецифичными. | * Существуют специальные стэндэлон настроечные среды (вебмин), которые тоже предназначены для того же самого. Может быть, но у лектора есть твёрдое ощущение, что необходимость в таких конфигураторах отпадает. Проблема в том, что это очень сложно. Вплоть до того, что выясниться, точ чем универсальнее тот инструмент, который управляется всем и вся, тем меньше пересечение. /* рассказ про патчинг купса и NU_IZVRAT */. То есть, они либо становятся дистрибутивоспецифичными, либо задачеспецифичными. | ||
| Строка 44: | Строка 38: | ||
* Должны быть внутри этого места, где мы держим настройки, должен быть гибкий формат представления. Чем опять же плох реджистри --- если мы говорим, что у нас древесная структура, то сразу вычёркиваем два класса сущностей --- организация в виде графа (tags), второе --- программы; они тоже могут быть штуками, которые управляют системой. То есть в нашем пространстве имён должны быть данные любые | * Должны быть внутри этого места, где мы держим настройки, должен быть гибкий формат представления. Чем опять же плох реджистри --- если мы говорим, что у нас древесная структура, то сразу вычёркиваем два класса сущностей --- организация в виде графа (tags), второе --- программы; они тоже могут быть штуками, которые управляют системой. То есть в нашем пространстве имён должны быть данные любые | ||
* Удобный инструментарий для чтения и модификации. Лектор сошлётся на свою идею более чем десятилетней давности --- существует такой критерий --- человекоприемлемости: кусок данных можно назвать пригодным, если его можно написать с нуля. | * Удобный инструментарий для чтения и модификации. Лектор сошлётся на свою идею более чем десятилетней давности --- существует такой критерий --- человекоприемлемости: кусок данных можно назвать пригодным, если его можно написать с нуля. | ||
| - | + | ||
| - | + | какая ситуация в линуксе: до сих пор это решается старым юниксовым способом --- любой файл --- человекочитаемый текст. Один из вопросов, который возник в процессе диалога с гуру --- что такое плоский текст. Когда лектор говорит про текстовый файл, то он имеет в виду файл в виде плоского текста. Если текст --- некий поток символов, тол плоский текст хранит только информацию, а размеченный текст хранит метаинформацию. То есть, когда вы видете плоский текст, то вы видите то, что должны видеть, а размеченный текст можно показывать в виде плоского текста и в формате представления. Так вот. Когда лектор говорит, что любой файл является текстовым, то это значит, что он всегда доступен как текст плоский, то есть его можно редактировать текстовым редактором. | |
Теперь попробуем описать, как это выглядит: | Теперь попробуем описать, как это выглядит: | ||
