Linux book/Install and configure
Материал из eSyr's wiki.
Содержание
|
Установка и настройка ПО
Поиск ПО: где брать?
Одной из насущных проблем сразу после установки операционной системы является установка и настройка ПО для решения конкретных задач. Возникает вопрос: какое ПО существует и откуда его брать? Самый простой (но и наименее информативный) ответ на этот вопрос дает команда apt-cache show *. Но это не единственный вариант. Подходить к поиску ПО (как и к любой другой задаче) можно по-разному. Рассмотрим некий виртуальный пример, который, тем не менее, довольно часто встречается в реальной жизни:
Приходит человек и говорит: «У меня вот Photoshop, а что у вас в Линуксе есть?». Ему, как правило, отвечают: «А у нас есть GIMP». После чего человек уходит, а через некоторое время возвращается и говорит, что в GIMP нет ничего из того, что ему надо. Это самый плохой подход — подход от названия.
Более сложный и обстоятельный способ — подход от инструмента. Он популярен у людей, которые в определённой мере ориентируются в предметной области. В данном примере, поскольку Photoshop — программа, связанная с графикой, можно рассмотреть инструменты, связанные с графикой. Выделяют два основных вида графики -- векторную и растровую. Векторная графика, в свою очередь, делится на плакатную, макетную и диаграммы. Для плакатной графики используются Inkskape, Xara Xtreeme, Kontour и ещё добрый десяток различных приложений. Про печатные макеты можно прочитать на Википедии, и, например, узнать, что программы на PostScript редактировать не надо (PostScript -- это язык. На нём даже вирус можно написать). Для работы с диаграммами есть Dia, Xfig, OpenOffice.org Draw. Что касается растровой графики, то есть программы для обработки фотографий — GIMP, Krita. Есть аналоги MS Paint — их бесконечно много, один хуже проще другого. Из них можно вспомнить Tux Paint, Kolourpaint. Также существуют пакетные преобразователи, позволяющие писать разнообразные скрипты, преобразующие картинки. Ярким примером подобного инструмента является ImageMagick. Можно вспомнить ещё про 3D-графику — Blender, POV-RAY. При таком подходе на пришедшего с вопросом человека в итоге сваливается 200 названий, человек уходит,а когда возвращается, говорит, что Linux ужасно крут, но не умеет делать то, что ему надо.
И, наконец, третий подход — это подход от задачи. Если расспросить человека о том, что ему нужно, возможно, окажется, что у него есть фотоаппарат и он хочет управлять каталогом фотографий, назначать им теги, убирать красные глаза, и так далее. В этом случае сразу появляется решение — DigiKam, и, возможно, ещё gfoto2, если у камеры специфический драйвер.
Таким образом, получаем три подхода:
- от названия
- от инструмента
- от задачи
Обычно пользуются первым, реже вторым. Но правильный — третий. Сначала необходимо определить круг решаемых задач. После определения круга задач возникает вопрос, где искать инструменты(то есть, программы) для их решения.
Откуда вообще берутся программы под Linux? Надо дать достаточно точный и полный ответ, ибо обычно ответ звучит как «лежат на диске» или «скачиваются из сети», что не даёт никакого представления о культуре поиска и установки ПО под Linux. Рассмотрим то, где на самом деле берут ПО для Linux.
Дистрибутив и репозиторий
Дистрибутив — скомпонованный и отлаженный набор подготовленных к использованию программ. Эти программы взяты из некоего большего, чем сам дистрибутив, хранилища. То есть, существует хранилище, где имеется большое количество ПО (на самом деле таких хранилищ, «репозиториев», несколько), и его часть используется для создания дистрибутива. В этом хранилище находятся одни из самых последних версий большого количества программ, и, если человек какую-то программу в нём не находит, он, при достаточной квалификации, может добавить недостающую программу (найденную другими путями, которые будут рассмотрены далее) в хранилище. При этом, поскольку полное тестирование всего добавляемого и обновляемого ПО не проводится, то возможна несовместимость между различными приложениями и невозможность использования отдельных программ на некоторых конфигурациях. Как следствие, комфортно использовать ПО из репозитория (а не из дистрибутива) можно только при достаточной квалификации.
Когда принимается решение о создании очередного дистрибутива, то создаётся замороженная копия репозитория, в которой обновления производятся только для исправления критических ошибок. Эта замороженная копия тестируется, отлаживается. В последствии на основании этой проверенной копии делается собственно дистрибутив. В результате, если ставить программу из дистрибутива, то, в идеале, ничего нештатного произойти не должно.
Другие варианты
Не исключена ситуация, при которой нужного приложения в используемом репозитории не оказывается. Так как хранилищ существует несколько, то при отсутствии искомой программы в том хранилище, на котором базируется используемый вами дистрибутив, можно попробовать поискать в других репозиториях. Где ещё можно попытаться найти интересующее ПО: существуют специализированные сайты, такие как SourceForge.net, где разработчикам предоставляются средства для ведения разработки, а пользователям — средства поиска по имеющимся проектам. Кроме этого, существуют независимые сайты разработчиков, где программы могут распространяться как в виде исходных текстов, так и в собранном виде.
Рецепт: как искать программы под Linux
В результате выстраивается некая схема поиска ПО:
- Искать в дистрибутиве
- Искать в репозитории
- Искать в чужом дистрибутиве.
- Поиск по специализированным сайтам (sourceforge, savannah (http://savannah.gnu.org/, http://savannah.nongnu.org/), freshmeat)
- Поиск в google на предмет сайта разработчика
- Если всё это проделали, и результатов нет, то не значит, что приложения не существует. Очень хороший источник информации — сообщество.
- Официальные информационные ресурсы (документация, сайт, wiki)
- Списки рассылки
- IRC, форумы
- Сообщество на последнем месте (несмотря на свою достаточно высокую эффективность) потому, что до этого на поиск тратятся только собственное время, а в сообществе тратят своё время другие люди.
Установка ПО
Установку программ в Linux лучше делать в рамках своего репозитория, но можно выделить ряд других способов установки ПО:
- Установка из чужого дистрибутива/репозитория
- Сборка из исходных кодов
- Бинарный инсталлятор
Перед тем, как подробно рассматривать каждую из указанных возможностей, определим ряд понятий, которые нам при этом потребуются.
FHS
В Linux существует строгая иерархия каталогов (File Hierachy System, FHS), которая описывает структуру каталогов и их семантику. Подробно FHS описан в учебнике Курячего Г. В. «Операционная система Linux». Так, в соответствии с FHS, существует 4 места для ПО, 2 каталога для разделяемых библиотек, 1 каталог для документации, и так далее. Каждая программа, состоящая из многих файлов, размещает их в соответствии с их предназначением в соответствующие каталоги в ФС.
Пример размещения некоторых типичных файлов абстрактной программы:
- /usr/bin/prog — исполняемый файл программы
- /usr/share/doc/prog/README — файл-описание программы
- /usr/share/man/1/prog.tgz — страница руководства по программе
И всё это входит в один программный продукт.
В Linux достаточно аккуратно проделано разделение прав доступа, и пользователь не имеет права доступа на запись к большей части файловой системы (за исключением своей домашней директории и /tmp/). Тем не менее, процессы, запущенные под суперпользователем игнорируют ограничения доступа. Поэтому установка ПО обычно делается под root'ом (поскольку при этом создаются файлы в каталогах, которые закрыты на запись для простых пользователей), и установку программ, кроме как в свой каталог, обычный пользователь, в отличие от root'а, осуществить не может.
Пакет
Одной из основополагающих единиц в процессе работы с хранилищем программного обеспечения является пакет.
Пакет — файл, содержащий всё необходимое для установки и удаления программного продукта.
То есть, для установки программного продукта достаточно установить пакет, и после этого он должен заработать. Для удаления программного продукта, соответственно, достаточно удалить пакет.
Рассмотрим подробно, что представляет собой пакет:
- Пакет — архив, содержащий файлы программного продукта. Причём, архив вполне известной структуры. Достаточно ли просто его разархивировать? Нет.
- Пакет обеспечивает регистрацию программного продукта в системе. Должен быть зарегистрирован список устанавливаемых файлов, а также некая метаинформация, такая как имя пакета, его версия, и так далее.
- Пакет обеспечивает первичную настройку программного продукта, то есть, запуск программы, специфичной для данного пакета — некоего установочного скрипта. Таких скриптов может быть несколько.
В связи с этим возникает ряд вопросов:
- Что делать, если одни пакеты зависят от других (например, один программный продукт и использует в своей работе другой)?
- Как разрешать конфликты, то есть, те случаи, когда при попытке установить файл из архива оказывается, что такой файл есть, и создан он не пользователем, а другим пакетом?
Зависимости
Перед рассмотрением проблемы зависимостей введём понятие разделяемой библиотеки.
Разделяемая библиотека — самостоятельный набор библиотек, используемый другими программными продуктами.
Преимущества использования разделяемых библиотек:
- При использовании библиотек программы занимают меньше места, так как экземпляр библиотеки один, а не отдельные экземпляры для каждого программного продукта, её использующего.
- Библиотека загружается в память один раз
- Для разделяемой библиотеки не нужно даже иметь место в swap — swap'ом этого файла будет файл на диске
- Если в библиотеке есть ошибка, то её быстро найдут, поскольку она используется во многих программах, и, как следствие, интенсивно тестируется
Но, при всех достоинствах разделяемых библиотек, появляется проблема -- задача разрешения зависимостей. Разделяемые библиотеки не входят в пакет. Каждая группа библиотек находится в отдельном пакете. Перед установкой программного продукта необходимо установить все библиотеки, которые им используются, то есть, удовлетворить его зависимости. Получается палка о двух концах: с одной стороны, использование разделяемых библиотек упрощает и ускоряет разработку; с другой стороны, усложняется порядок установки программ — необходимо скачать и установить в правильном порядке всё дерево (точнее, ациклический орграф) зависимостей. В большинстве дистрибутивов Linux для автоматизации удовлетворения зависимостей существуют две программы — установщик и менеджер пакетов, которые подробно рассмотрены далее.
Кроме этого существуют непрямые зависимости. Возможна ситуация, когда для работы вашего продукта другой программный продукт не является необходимым, но с ним связана некая некритичная функциональность. Например, для почтового веб-сервера не обязательно нужен почтовый сервер, поэтому установка почтового сервера не должна требоваться, но его можно оформить как рекомендованный пакет, поскольку первое без второго используется редко.
Конфликты
Иногда при установке очередного пакета может возникнуть так называемый конфликт.
Конфликт — ситуация, при которой файлы из разных пакетов должны иметь одинаковые абсолютные имена/*абсолютное имя – откуда термин?не лучше ли «полностью одинаковые имена и пути»*/.
Пример конфликта: пакеты с различными вариантами vi: vi, vim-minimal, mvi пытаются установить бинарный файл /usr/bin/vi.
Существует метод, позволяющий разрешать конфликты — альтернатива. Для каждого пакета выбираются свои уникальные имена (в данном примере — /usr/bin/vi.original, /usr/bin/vim, /usr/bin/mvi). Кроме этого, создаётся файл с конфликтным именем (/usr/bin/vi), но он является символической ссылкой на один из файлов, боровшихся за данное имя. То, куда будет указывать символическая ссылка, решается при помощи отдельного механизма(например назначением пакетам некоторых весов и ссылкой на файлы пакета с наибольшим весом).
Установщик пакетов
Как сказано выше, единицей ПО считается пакет. Пакет обладает массой свойств — это не только распаковка, но и регистрация в системе, запуск некоторых сценариев при установке/удалении. Работой с отдельным пакетом занимается установщик.
Установщик — утилита, которая позволяет управлять отдельным пакетом. Сюда входят установка и удаление, проверка пакета на различные свойства, просмотр различий в версиях пакета, проверка зависимостей, и так далее.
По историческим причинам, в список обязанностей установщика пакетов входит также их сборка пакетов из их исходных версий. В исходную версию пакета (src package) входит вся инфрмация, необходимая для его сборки.
Важно отметить, что установщик пакетов работает только с отдельными файлами, а не с репозиторием. Этот факт подробнее будет рассмотрен далее.
На данный момент существует определённое количество форматов пакетов и утилит по работе с ними. Наиболее популярными являются два следующих формата:
- RPM, RPM (ранее RedHat) Package Manager. Изначально появился в дистрибутиве Red Hat Linux. На данный момент используется в большом количестве RedHat-based (и не только) дистрибутивов, в число которых (косвенно, посредством Mandrake Linux) входит и ALT Linux. Установщиком для данного формата пакетов является одноимённая утилита rpm[1].
- DEB, Debian software package. Формат, разработанный в рамках дистрибутива Debian и использующийся большей частью в Debian-based дистрибутивах. Отличается гибкостью процесса установки пакетов. Установщиком для данного формата пакетов является утилита dpkg.
Помимо упомянутых двух форматов, существует и много других, например, свой формат пакетов используется в дистрибутиве Gentoo, свой формат пакетов в самом старом дистрибутиве Slackware.
Рассмотрим, как выполняются основные операции по рабте с пакетами:
- Установка
- rpm -i <file>.rpm
- dpkg -i <file>.deb
- Удаление
- rpm -e <file>.rpm
- dpkg -r <file>.deb
Покажем, что пакет является архивом.
- Пакет в формате RPM состоит из заголовочной части и архива в формате cpio (иногда сжатого архиватором gzip или bzip2). Для извлечения архива из пакета существует утилита rpm2cpio, которая выводит файл в формате cpio. Далее можно, например, посмотреть листинг находящихся в архиве файлов, выполнив rpm2cpio | cpio -itv.
[user@demo ~]$ rpm2cpio zip-2.32-alt2.S40.1.i586.rpm | cpio -itv -rwxr-xr-x 1 root root 66808 Jun 25 17:16 ./usr/bin/zip -rwxr-xr-x 1 root root 26616 Jun 25 17:16 ./usr/bin/zipcloak -rwxr-xr-x 1 root root 22548 Jun 25 17:16 ./usr/bin/zipnote -rwxr-xr-x 1 root root 26580 Jun 25 17:16 ./usr/bin/zipsplit drwxr-xr-x 2 root root 0 Jun 25 17:16 ./usr/share/doc/zip-2.32 -rw-r--r-- 1 root root 401 May 18 2006 ./usr/share/doc/zip-2.32/BUGS -rw-r--r-- 1 root root 77392 Jun 20 2006 ./usr/share/doc/zip-2.32/CHANGES -rw-r--r-- 1 root root 2692 Apr 10 2000 ./usr/share/doc/zip-2.32/LICENSE -rw-r--r-- 1 root root 42404 Jun 20 2006 ./usr/share/doc/zip-2.32/MANUAL -rw-r--r-- 1 root root 8674 Apr 14 2006 ./usr/share/doc/zip-2.32/README -rw-r--r-- 1 root root 3149 Feb 21 2005 ./usr/share/doc/zip-2.32/TODO -rw-r--r-- 1 root root 3382 Jun 20 2006 ./usr/share/doc/zip-2.32/WHATSNEW -rw-r--r-- 1 root root 19032 Apr 19 2000 ./usr/share/doc/zip-2.32/WHERE -rw-r--r-- 1 root root 12398 Jun 20 2006 ./usr/share/man/man1/zip.1.bz2 614 blocks
- Пакет в формате DEB представляет собой архив в формате ar[2], состоящий из двух архивов в формте gzip или bzip2: с контрльной информацией и с данными.
[user@demo ~]$ ar vt libwxsmithlib0_8.02-0ubuntu1_i386.deb # Выводит список файлов в архиве ar с дополнительной информацией rw-r--r-- 0/0 4 Feb 28 01:22 2008 debian-binary rw-r--r-- 0/0 716 Feb 28 01:22 2008 control.tar.gz rw-r--r-- 0/0 1056018 Feb 28 01:22 2008 data.tar.gz [user@demo ~]$ ar vx libwxsmithlib0_8.02-0ubuntu1_i386.deb # Распковка x - debian-binary x - control.tar.gz x - data.tar.gz [user@demo ~]$ ls control.tar.gz data.tar.gz debian-binary libwxsmithlib0_8.02-0ubuntu1_i386.deb [user@demo ~]$ tar -ztvf control.tar.gz # Просмотр списка имеющихся в архиве файлов drwxr-xr-x root/root 0 2008-02-28 01:22 ./ -rw-r--r-- root/root 405 2008-02-28 01:22 ./control -rwxr-xr-x root/root 132 2008-02-28 01:21 ./postrm -rwxr-xr-x root/root 135 2008-02-28 01:21 ./postinst -rw-r--r-- root/root 221 2008-02-28 01:22 ./md5sums -rw-r--r-- root/root 31 2008-02-28 01:21 ./shlibs [user@demo ~]$ tar -ztvf data.tar.gz drwxr-xr-x root/root 0 2008-02-28 01:21 ./ drwxr-xr-x root/root 0 2008-02-28 01:21 ./usr/ drwxr-xr-x root/root 0 2008-02-28 01:21 ./usr/lib/ -rw-r--r-- root/root 3291092 2008-02-28 01:21 ./usr/lib/libwxsmithlib.so.0.0.1 drwxr-xr-x root/root 0 2008-02-28 01:21 ./usr/share/ drwxr-xr-x root/root 0 2008-02-28 01:21 ./usr/share/doc/ drwxr-xr-x root/root 0 2008-02-28 01:21 ./usr/share/doc/libwxsmithlib0/ -rw-r--r-- root/root 406 2008-02-28 00:30 ./usr/share/doc/libwxsmithlib0/copyright -rw-r--r-- root/root 4979 2008-02-28 00:51 ./usr/share/doc/libwxsmithlib0/changelog.Debian.gz lrwxrwxrwx root/root 0 2008-02-28 01:21 ./usr/lib/libwxsmithlib.so.0 -> libwxsmithlib.so.0.0.1
Все перечисленные выше свойства пакетов (способ установки, регистрация в системе, установочные скрипты, зависимости, разрешение конфликтов) и формат RPM, и формат DEB поддерживают.
Сборка пакетов =
И rpm, и dpkg позволяют собрать пакет.
Процесс сборки в пакет специфицирован, во всех крупных дистрибутива существует сглашения по тому, что должно входить в пакет, каков процесс сборки и установки.
При этом первое, что надо учитывать, это то, что разработчики ПО имеют свои собственные, отличные от политики дистрибутива, представления о том, где какие файлы должны находиться. Например, есть приложение eaglemode, которое устанавливается а-ля приложения для Solaris: /opt/eaglemode/{bin|lib|res|etc}. Это — одна из причин, по которой в процессе подготовки к сборке пакета необходимо модифицировать исходный код продукта. Для облегчения процесса подготовки ПО в соответствии с полиси дистрибутива есть набор утилит patch. Это позволяет ментейнеру не делать изменения с 0 для каждой новой версии, он оформляет сделанные изменения в виде патча, который потом накладывается на оригинальный вариант ПО.
В результате, в процессе подготовки ПО к сборке в пакет нужно выполнить следующие действия:
- Оформить отличия в виде патчей
- Написать команды по сборке
- Организовать предустановочный и послеудалятельный сценарий
- Заполнить паспорт пакета
В RPM для этих целей служит spec-файл, в которым всё это лежит, за исключением больших файлов, которые лежат отдельно. Скачанный исходник, spec-файла и дополнительные файлы составляют src.rpm. Из него и собирается rpm.
В DEB имеется несколько различных файлов, каждый служит своим целям. В файле control указывается различная метаинформация: название пакета, описание, зависимости (паспорт пакета). В rules находятся команды по сборке пакета (makefile для утилиты dh_make). Скрипты, которые должны выполняться в процессе установки и удаления пакета, размещаются в файлах postinst, preinst, postrm, prerm. Существует ещё ряд служебных файлов (changelog, dirs, README, ...) служащих различным целям. Команда debuild собирает DEB-пакет с использванием этих файлов.
Появляется второй род зависимостей: зависимости, необходимые для сборки пакета (build requirements).
Из этого можно сделать вывод, что rpm для обычного пользователя программа не очень удобная. Поскольку при попытке установить покет может оказаться, что не удовлетворены изх зависимости, для них не удовлетворены их и так дале. Причём rpm не может отследить их все, они в пакете не написаны, там только непосредственные зависимости. Но со своей задачей rpm справляется.
Менеджер пакетов
По традиции, установщик также используется для сборки пакета. Но это не столь важно, сколь другая особенность установщика: он работает с одним файлом, а для управления всеми доступными пакетами необходим диспетчер (менеджер) пакетов, который работает сразу с хранилищами пакетов. В итоге, задача диспетчера состоит в построении графа зависимостей, разрешения вопроса о получении недостающих пакетов (скачивания их из доступных источников) и их установке.
Поэтому для решения этих задач используется диспетчер пакетов. В альте используется apt? Advanced Package Tool. Он взят из дебиавна, в котором ещё и свой формат пакетов --- dpkg. Он был достаточно универсален, чтобы после нескольких ударов кувалдой он начинал использовать rpm. Причём его писали такие хакеры, что можно и кувалду сломать.
Мы уже описали ситуацию, пр и которой установщик пасует. Что же ... .
- Пользователь совершенно не обязан указывать версию пакета. Откула apt узает версию пакета? В отличие от установщикА, диспетчер пакета работает с хранилищами пакетов. Он знает, где лежат все пакеты, которые я могу захотеть установить. Хранилищ может быть несколько. Диспетчер кеширует индексы. Соответственно, есть две утилиты --- apt-get , который работает с хранилищами непосредственно, и apt-cache, котрый работает с кэшем.
Соответственно, диспетчер делает то, что не может установщик: строит дерево зависимостей, получает необходимые и запускает их установку.
- apt-get install <имя пакета> --- установка пакета
- apt-get remove <имя пакета> --- удаление пакета
- apt-get update --- обновление индексов
Таким образом, на долю утилиты apt ложится обновление из изменяющегося хранилища.
- apt-cache search --- ищет имтроку в именах пакетов, их описаниях и файлах
У обоих команд (rpm и apt) есть дикое количество ключей.
Кроме апта, есть есть графические утилиты для работы с пакетами.
Любая команда по работе с системой должна выполняться с правами суперпользвователя.
Ровно одна задача --- модификация самой системы --- делается с правами суперпользователя.
Виды программ
(отсортировано по вероятности того, что программа заработает в вашей системе)
- Бинарники — первый и самый наименее вероятный уровень.
- Подвиндовз + wine
- Wine имеет двух наследников — Wine intersoft и crossover office, небесплатных
- Бинарники под Linux
- Для того, чтобы такая программа нормально заработала нужно кроме программы предоставить все библиотеки, с которыми она собрана. Статическая сборка/с библиотеками
- Если не статически собраны, то возникает проблема с версиями библиотек и размещением конфиг. файлов.
- Практика показывает, что эта степень подлинуксовости — низшая
- Подвиндовз + wine
- Программа на Си++
- Тоже низшая степень подлинуксовости. Если я написал программу, она компилируется и работает, то я написал программу под Линукс. Такие проекты либо очень быстро задыхаются (ибо программа работает только на той машине, где писалась), либо очень простые
- Сборка? Во многих случаях это возможно, но никакой гарантии нет
- Уровень крибле-крабле-бумс — использование Autotools
- Способ делать более-менее кроссплатформенноен приложение. Они делают мейк-файл, который позволяет собирать программу на большом количестве систем. Вероятность сборки повышается, особенно если у вас просто линукс, а линукс это мейнстрим.
- Кто и как часто собирает? Если нужно установить программу на нескольких машинах то что, надо всё время скачивать и пересобирать? Сборка это невоспроизводимый процесс (на разных машинах — разные программы)
- Пакеты другого дистрибутива (чужой пакет). Есть некоторая вероятность, что он не заработает.
- Всё равно встаёт вопрос соместимости по библиотекам
- Поскольку пакет не вашего дистрибутива, то он не входит в структуру. Вы обновляете дистрибутив, а пакет не обновляется. Дело в том, что когда вы дообновляетесь до того, что обновятся библиотеки так, что пакет перестанет работать, то надо что-то делать.
- spec-файл (для rpm). Можжно взять src.rpm и spec-файл, то можно попытаться собрать его, подсунув свои библиотеки.
- Опять попадаете в ситуацию сизифового труда. Взяли спек, подправили баги, собрали, всё это в одиночку. Послезавтра если это надо будет установить на другой машине, то собирать придётся с начала.
- Это не пакет. Он не обновляется, и т. д.
- Можно доработать его до пакета, положить в дистрибутиьв и стать maintainerом этого пакета.
- Пакет дистрибутива.
Один забавный факт. Человек, от линукса далёкий, будет искать сверху вниз. Человек недалёкий будет делать это в обратном порядке.
В последнем случае получаются много бонусов.
Ровно до момента "чужой пакет" вы не являетесь членом сообщества вообще. И только в последнем случае вы — полноправный член сообщества. Единственное, чем этот путь плох — этот путь не для простого пользователя, это путь для разработчика.
Джава — ОС в ОС. Со стороны maintainerов дистрибутива, нужно положить в дистрибутив Джава-машину, эклипс и всё. (...)
Как искать программы под Linux
- Искать в дистрибутиве (apt-cache search).
- Поиск в собственном дистрибутиве
- Поиск в бэкпортах — сборка новых программ под старые дистрибутивы (окружения)
- Поиск в тестовой версии
- Искать в чужом дистрибутиве.
- Вероятность довольно высокая потому, что много людей пытались собрать эту программ до вас
- src.rpm
- rpm
- Поиск по разработчикам (sourceforge, savanna, freshmeat). Они выдадут по ключевым словам, какие существуют программные продукты, соотвествующие ключевым словам. Из этого списка нужно выбрать несколько кандидатов, посмотреть их, понять, почему до вас не собрали, собрать...
- Это может не помочь по двум причинам
- Не все проекты, особенно проекты экзотические (академические) попадают на эти порталы. Но елси у людей есть сайт, то крупные поисковые системы наверняка их проиндексировали по тем же ключевым словам (go google)
- Это может не помочь по двум причинам
- Если всё это проделали, и результатов нет, то не значит, что софта не существует. Очень хороший источник информации — сообщество.
- Поиск сообщества
- Поиск ресурса в сообществе
- Официальные информационные ресурсы (документация, сайт, wiki)
- Списки рассылки
- IRC, форумы (если игнор-лист правильно настроить)
Спепцифика установки ПО из различных источников
Установка ПО из своего дистрибутива
В рамках дистрибутива всё будет хорошо.
Установка ПО не из своего дистрибутива
Установка из хранилища
Когда вы обращаетесь к хранилищу, может случиться, что появились версии программ и все поменялось. В этом случае применим следующий способ: помимо rpm есть src.rpm, в котором содержится всё необходимое для сборки программного продукта. Можно скачать src.rpm и пересобрать его в своём окружении. Всё сводится к выполнению новых команд:
- Скачать src.rpm
- Собрать. Образуется бинарный rpm
- У нового бинарного rpm не будет проблем с зависимостями
Установка из другого репозитория
Проблема с чужим репозиторием может заключаться в том, что разделяемые библиотеки могут находиться в пакетах с другими именами.
Кроме того, пакеты из чужих репозиториев не обновляются/*автоматически?ручками то можно*/, что с определённого момента не позволит обновлять зависимые библиотеки, а также пакеты, которые зависят от этих библиотек.
Сборка из исходных кодов
Существует два основных способа: сборка с использованием вручную написанного makefile и сборка с использованием autotools. Основная проблема в том, что если активно пользоваться программой, то при каждой новой версии выполняется последовательность команд configure, make, make install, в результате чего возникает большое количество версий одних и тех же библиотек, удалить которые нельзя, так как их может использовать кто-то ещё. Кроме того, может получиться, что старые библиотеки используются вместо новых.
Установка бинарника
Одна из проблем с бинарными файлами заключается в том, что они могут использовать свои библиотеки определённой версии, что никак не контролируется в рамках репозитория. Выходов два: сборки под разные дистрибутивы средствами разработчика или статическая сборка всех используемых библиотек. Стоит отметить, что в последнем случае гораздо больше вероятность, что запустится бинарник, чем пакет из другого дистрибутива.
В общем случае не рекомендуется пользоваться бинарными инсталляторами. Правильно сделанные инсталляторы выполняют установку в соответствии с FHS, то есть, производят установку одним из нижеуказанных способов:
- В самом лучшем случае делается следующее: в /opt/ (в который ставятся программы вне дистрибутива) будет /opt/(program name)/{bin, lib, ...} Единственная проблема разработчиков --- заставить запускаться бинарник оттуда. Поэтому даже в этом случае он создаст в /usr/bin/ специальный файл для запуска приложения (это плохо тем, что в стандартом каталоге будет файл, не принадлежащий ни одному пакету).
- Чуть менее хороший вариант — установка в /usr/local/{bin, lib, ...}. /usr/local/ — то, что живёт только на вашей системе и должно быть сохранено после удаления системы и установки новой. Чем это плохо — может возникнуть конфликт имён. Чем это лучше — /usr/local/ обычно есть в PATH и установщик больше нигде файлы создавать не будет.
И то, и другое должно происходить от имени суперпользователя, что потенциально порождает проблемы (как и в любом другом случае установки ПО, но данный усугубляеется тем, что нельзя проконтролировать процесс). Как альтернатива, существуют директории ~/bin и ~/.local, в которые можно произвести инсталляцию, не имея прав root'а, но отнюдь не всегда эти пути прописаны в PATH./*мб все таки пояснить что такое PATH и почему там все должны быть прописаны? сноской.*/
Резюме
По возможности (в частности, в случае использования пакетов из других хранилищ или сборки из исходных текстов) надо собирать пакеты и добавлять их в используемый репозиторий. Это позволит избежать проблем, связанных с зависимостями и обновлениями./*Резюме скорее для разработчиков, а не для детей. */
Настройка
Это довольно нетривиальный и важный вопрос, рассмотрим основные темы, с этим связанные:
- Пространство имён. Необходимо настраивать всю систему целиком, следовательно, должен быть такой способ именования настроек, что в нём было бы легко ориентироваться. Например, единая древовидная структура — пример плохой организации
- Гибкость формата представления настроек. Например, если жёстко задана древовидная структура, то в такой структуре отпадает организация в виде графа (tags),или в виде программы; они/*что за таинственные они?граф управляет системой?о_О*/ тоже могут быть штуками, которые управляют системой. То есть, в рассматриваемом пространстве имён необходимо предусмотреть возможность нахождения данных произвольной структуры
- Удобный инструментарий для чтения и модификации. В случае с настройкой разумно рассматривать критерий человекоприемлемости: кусок данных можно назвать человекиприемлемым, если человек может его написать с нуля.
Текстовые конфигурационные файлы
В Linux до сих пор это/*надо конкретизировать «это»*/ решается старым, UNIX-way, способом: любой файл, с которым возможна работа пользователя — человекочитаемый текст. Опишем, как это выглядит:
- Пространство имён — файловая система. Зачем множить сущности (дерево), если дерево уже есть. В /etc/ лежат файлы, необходимые для настройки остальной части системы
- Каждый файл принадлежит пакету, и названия в etc соответствуют названиям пакетов. Это способ локализации информации о настройках
- Гибкость представления. Файлы настройки могут иметь произвольные синтаксис и семантику: пары ключ-значение, XML-файлы, скрипты.
- Чтение и модификация. С одной стороны, есть графические программы настройки (подробнее про них далее). В каком-то смысле они удобные. Но графический интерфейс хорошо подходит для настройки графического интерфейса и стандартных типовых задач. А каковы должны быть инструменты, которые бы позволили читать и изменять практически любой конфигурационный файл, учитывая его произвольные синтаксис и семантику? Поскольку мы договорились, что конфигурационные файлы представляются в виде текста, то у нас есть способ работы с ними — текстовый редактор (в случае, если не стоит задач автоматизации работы). Но редактор конфигурационных файлов должен обладать не совсем таким набором возможностей, каким должен обладать редактор текста. При редактировании литературного текста обычно необходимо уметь проверять орфографию, писать и писать, и потом, в конце, возможно, переставить пару абзацев. Тогда как при работе с конфигурационными файлами элементы разметки и другие синтаксические единицы служат объектами оперирования. Типичный способ работы состоит в том, что находится необходимая секция, в которой хранится свойство, и оно изменяется. Поэтому редактор файлов настроек, должен уметь быстро производить поиск, ручную и авотматизированную модификацию. Типичный пример: заменить имя хоста во всех конфигурационных файлах. Почему бы это не оформить в виде парсера? Некоторые задачи можно решить вручную, но некоторые задачи можно решить автоматизированно, и лучше, чтобы таких задач было как можно больше. И в таких случаях нужны процессоры обработки текста.
Яркими примерами инструментов для работы с текстовыми файлами вообще и с конфигурационными файлами в частности являются такие программы, как vim и emacs. Но перед тем, как с ними работать, необходимо сначала научиться ими пользоваться. Для случае же, когда нужно работать сразу, есть такие программы, как nano, mc, kate, evim.
Конфигураторы
Несмотря на наличие развитых средств по работе с текстовыми файлами конфигурации, имеются графические средства конфигурирования. Причины этого явления понятны: человек привык выбирать «панель управления», и там есть «всё», что можно настроить. Понятно, что там явно не всё и если бы показали всё, то человек впал бы в подавленное состояние духа. Когда пользователь открывает окно настройки он видит графического плана утилиты, которые что-то настраивают. Они бывают 4 сортов:
- Настройка каких-либо графических приложений (KDE Control Center, который в первую очередь настраивает KDE). Наиболее правильный тип. Если само приложение графическое, то и настройщик логично делать графический. В большинстве графических приложений есть пункт «настройка», но существуют и настройщики в виде отдельных программ.
- Не столь однозначный вариант, когда программы настройки того же KDE имеют средства для настройки системы. Пример: является ли системной настройка частоты обновления и разрешения экрана? Казалось бы, нет,но с другой стороны этот параметр точно в ведении/*в ведомости у администраторов зарплата обычно*/ администратора сиситемы, так как необходима правка конфигурационного файла графической подсистемы.. В том же KDE Control Center или Gnome можно увидеть ряд подобных утилит, что есть следствие парадигмы «системы в рамках рабочего стола». Идея в следующем: разработчики, которые делают рабочий стол, считают, что разрешение — характеристика рабочего стола, поэтому должны быть инструменты для настройки, если же нет, то нет. Поэтому не обязательно, что эти инструменты из графической подсистемы обязаны заработать.
- Настройка системы в масштабе дистрибутива. Если создатели дистрибутива решили облегчить жизнь пользователю, то создаётся конфигуратор который объявляется системным (alterator в AltLinux, Yast в SuSE). Имеет смысл обратить внимание на этот конфигуратор, поскольку его точно тестируют. Правда, обычно в этих конфигураторах не так много всего и есть. Но это связано со спецификой дистрибутива.
- Настройка некоторых специальных служб, которые имеют собственный графический/веб интерфейс. Есть как минимум две таких службы — CUPS и Samba. Почему эти конфигураторы выделяются отдельно — конфигуратор к таким мощным системам разработчик дистрибутива просто не будет создавать и поддерживать.
- Существуют специальные standalone настроечные среды (наиболее характерным примером является webmin), которые тоже предназначены для того же самого — настройки системы. Есть мнение, что необходимость в таких конфигураторах отпадает. Проблема в том, что разрабатывать и поддерживать подобные конфигураторы очень сложно, вплоть до того, что выясняется, что чем универсальнее тот инструмент, который управляет всем и вся, тем меньшим количеством настроек он управляет. То есть, подобные конфигураторы становятся специфическими либо для дистрибутива, либо для задачи.
- Существует ещё ряд вещей, например, web-движки, которые опять же настраиваются через web-интерфейс.
Тем не менее, это не позволяет настраивать всю систему, только определённую её часть, и, как следствие, не решает задачу настройки в общем случае.
Где искать ответы на вопросы
...
Ссылки
- Виды ПО пд Linux
- Пакет
- Установщик, каталоги, настройка
- Лекция про информационный поиск
- Лекция про структуру дистрибутива и пакеты
- Лекция про установщик и менеджер пакетов
