Основы Linux от основателя Gentoo. Часть 2 (2/5): Назначения папок, поиск файлов

Автор оригинала: Daniel Robbins, Chris Houser, Aron Griffis
  • Перевод
В данном отрывке рассказано о стандарте иерархии файловой системы (FHS), почему директории так называются и для чего они нужны. Упомянута переменная окружения PATH и разобраны основные команды для поиска файлов в системе, такие как whereis, find и locate (slocate).



Навигация по основам Linux от основателя Gentoo:

Часть I
  1. BASH: основы навигации (вступление)
  2. Управление файлами и директориями
  3. Ссылки, а также удаление файлов и директорий
  4. Glob-подстановки (итоги и ссылки)

Часть II
  1. Регулярные выражения (вступление)
  2. Назначения папок, поиск файлов
  3. Управление процессами
  4. Обработка текста и перенаправления
  5. Модули ядра (итоги и ссылки)



FHS и поиск файлов


Стандарт иерархии файловой системы


Стандарт иерархии файловой системы (Filesystem Hierarchy Standard или сокр. FHS) — это документ который определяет схему директорий в Linux-системах. FHS разработан чтобы представить общую схему для упрощения независимой от дистрибутива разработки программного обеспечения, поскольку так все необходимое располагается одинаково в большинстве дистрибутивов. FHS определяет следующее дерево директорий (взято непосредственно из спецификации):


  • / (корневая директория)
  • /boot (статичные файлы загрузчика)
  • /dev (файлы устройств)
  • /etc (специфические для хоста конфигурационные файлы)
  • /lib (основные разделяемые библиотеки и модули ядра)
  • /mnt (точка монтирования для временных нужд)
  • /opt (дополнительные пакеты ПО)
  • /sbin (основные системные программы)
  • /tmp (временные файлы)
  • /usr (вторичная иерархия)
  • /var (изменяемые данные)

Две независимые классификации в FHS


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



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



+------------+-----------------+---------------+
|            | разделяемые     | неразделяемые |
+------------+-----------------+---------------+
| статичные  | /usr            | /etc          |
|            | /opt            | /boot         |
+------------+-----------------+---------------+
| изменяемые | /var/mail       | /var/run      |
|            | /var/spool/news | /var/lock     |
+------------+-----------------+---------------+

Вторичная иерархия в /usr


Внутри /usr вы обнаружите вторичную иерархию, которая выглядит очень похоже на корневую файловую систему. Для /usr не критично существование во время включения машины, она может быть общим сетевым ресурсом (разделяема) или примонтирована с CD-ROM (статична). Большинство конфигурация Linux не используют «разделяемость» /usr, но ценно понимать полезность отличия между основной иерархией в корневой директории и вторичной иерархией в /usr.



Это все, что мы расскажем о стандарте иерархии файловой системы. Сам по себе документ довольно читабелен и вам стоит на него взглянуть. После его прочтения вы будете гораздо лучше понимать файловую систему Linux. Найти спецификацию можно здесь: http://www.pathname.com/fhs/.



Поиск файлов


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



PATH


Когда вы запускаете программу из командной строки, bash начинает просматривать список директорий в поисках программы которую вы указали. Например, когда вы вводите ls, bash в действительности не знает, что программа ls находится в /usr/bin. Вместо этого, он ссылается на переменную окружения называемую PATH, которая содержит список директорий разделенных двоеточием. Мы можем проверить значение PATH:



$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin.


С таким значением PATH (у вас оно может быть другим) bash сначала проверит директорию /usr/local/bin, затем /usr/bin в поисках программы ls. Скорее всего, ls находится в /usr/bin, тогда на этой директории bash прекратит поиск.



Изменение PATH


Вы можете расширять переменную PATH, присваивая ей новое значение в командой строке:



$ PATH=$PATH:~/bin
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/home/agriffis/bin


Вы также можете удалять элементы из PATH, хотя это не так просто, поскольку вы не можете ссылаться в команде на существующий $PATH. Лучший вариант — это просто заново указать в PATH то, что вам нужно:



$ PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:~/bin
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/agriffis/bin


Чтобы сделать ваши изменения PATH доступными для процессов, которые будут запускаться в командной оболочке, необходимо «экспортировать» их используя команду export:



$ export PATH

О команде «which»


Вы можете проверить, есть ли конкретная программа в вашем PATH используя which. В следующем примере мы видим, в каталогах PATH нашей системы, программы с названием sense нет:



$ which sense
which: no sense in (/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin)


В этом примере, ls успешно находится:



$ which ls
/usr/bin/ls


which -a


Наконец, вы должны знать о флаге -a, который укажет which показать вам все экземпляры программы в PATH:



$ which -a ls
/usr/bin/ls
/bin/ls


whereis


Если вам необходимо больше информации о программе, чем просто ее расположение, вы можете воспользоваться командой whereis:



$ whereis ls
ls: /bin/ls /usr/bin/ls /usr/share/man/man1/ls.1.gz


Здесь мы видим что ls находится в двух каталогах с общими исполняемыми файлами, /bin и /usr/bin. Кроме того, нам сообщили что есть документация, которая находится в /usr/share/man. Это man-страница которую вы увидите, если введете man ls.



Программа whereis может использоваться для поиска расположения исходников и нестандартного поиска (имеется ввиду возможность искать файлы для которых отсутствуют маны, исходники или бинарники — прим. пер.). Также ей можно указать альтернативные пути для поиска. Обратитесь к man-странице для получения дополнительной информации.

find


Команда find это другой удобный инструмент в вашем арсенале. Используя find вы не ограничены лишь поиском программ; вы можете искать любые типы файлов, используя различные критерии поиска. Например, поищем в директории /usr/share/doc, файл который называется README:



$ find /usr/share/doc -name README
/usr/share/doc/ion-20010523/README
/usr/share/doc/bind-9.1.3-r6/dhcp-dynamic-dns-examples/README
/usr/share/doc/sane-1.0.5/README


find и шаблоны


Вы можете использовать glob-шаблоны для аргументов -name, при условии что вы экранируете их кавычками или обратным слешем (таким образом они будут переданы команде в нетронутом виде, иначе они сначала будут развернуты bash'ем и уже после переданы команде). Давайте поищем все файлы README с расширением:



$ find /usr/share/doc -name README\*
/usr/share/doc/iproute2-2.4.7/README.gz
/usr/share/doc/iproute2-2.4.7/README.iproute2+tc.gz
/usr/share/doc/iproute2-2.4.7/README.decnet.gz
/usr/share/doc/iproute2-2.4.7/examples/diffserv/README.gz
/usr/share/doc/pilot-link-0.9.6-r2/README.gz
/usr/share/doc/gnome-pilot-conduits-0.8/README.gz
/usr/share/doc/gimp-1.2.2/README.i18n.gz
/usr/share/doc/gimp-1.2.2/README.win32.gz
/usr/share/doc/gimp-1.2.2/README.gz
/usr/share/doc/gimp-1.2.2/README.perl.gz
[еще 578 строк опущено]


Игнорирование регистра в find


Конечно, вы можете игнорировать регистр при поиске:



$ find /usr/share/doc -name '[Rr][Ee][Aa][Dd][Mm][Ee]*'

Или, намного проще:



$ find /usr/share/doc -iname readme\*

Как видно, для поиска без учета регистра можно использовать опцию -iname .



find и регулярные выражения


Если вы знакомы с регулярными выражениями, вы можете использовать опцию -regex для поиска файлов с именами соответствующими шаблону. А также опцию похожую на -iname, которая называется -iregex и заставляет find игнорировать регистр в шаблоне. Пример:



$ find /etc -iregex '.*xt.*'
/etc/X11/xkb/types/extra
/etc/X11/xkb/semantics/xtest
/etc/X11/xkb/compat/xtest
/etc/X11/app-defaults/XTerm
/etc/X11/app-defaults/XTerm-color


Однако в отличии от большинства программ, find требует чтобы регулярное выражение указывалось для всего пути, а не только его части. По этой причине, стоит в начале и конце шаблона ставить .*; простого использования xt в качестве шаблона будет недостаточно.



find и типы файлов


Опция -type позволяет искать в файловой системе файлы определенного типа. Возможные аргументы для -type это: b (блочное устройство), c (символьное устройство), d (директория), p (именованый канал), f (обычный файл), l (символическая ссылка), и s (сокет). Например, поиск символической ссылки в /usr/bin, которая содержит в своем имени строку vim:



$ find /usr/bin -name '*vim*' -type l
/usr/bin/rvim
/usr/bin/vimdiff
/usr/bin/gvimdiff


find и mtimes


Опция -mtime позволяет вам искать файлы основываясь на дате их последней модификации. Аргументом mtime является количество 24-часовых периодов, и наиболее полезным будет указывать перед аргументом плюс (означает «после») или минус (означает «перед»). Например, рассмотрим следующий сценарий:



$ ls -l ?
-rw------- 1 root root 0 Jan 7 18:00 a -rw------- 1 root root 0 Jan 6 18:00 b -rw------- 1 root root 0 Jan 5 18:00 c -rw------- 1 root root 0 Jan 4 18:00 d

$ date
Tue Jan 7 18:14:52 EST 2003


Вы можете найти файлы, которые были модифицированы за последние 24 часа:



$ find . -name \? -mtime -1
./a


Или файлы которые были изменены до текущего 24-часового периода:



$ find . -name \? -mtime +0
./b
./c
./d


Опция -daystart


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



$ find . -name \? -daystart -mtime +0 -mtime -3
./b
./c
$ ls -l b c
-rw------- 1 root root 0 May 6 18:00 b -rw------- 1 root root 0 May 5 18:00 c

Опция -size


Опция -size позваляет искать файлы по их размеру. По-умолчанию, аргумент -size это количество 512-байтных блоков, но добавляя к опции суффикс, можно сделать вывод более понятным. Доступные суффиксы: b (512-байтные блоки), c (байт), k (килобайт), и w (2-байтные слова). Дополнительно, перед аргументом можно указать плюс («больше чем») или минус («меньше чем»).



Например, для поиска обычного файла в /usr/bin размер которого меньше 50 байт:



$ find /usr/bin -type f -size -50c
/usr/bin/krdb
/usr/bin/run-nautilus
/usr/bin/sgmlwhich
/usr/bin/muttbug


Работа с найдеными файлами


Вы даже не представляете, что можно делать с найденными файлами! Итак, find может производить любые действия над файлами используя опцию -exec. Эта опция принимает строку команд для выполнения, которая оканчивается на ;, и заменяет все вхождения {} именем файла. Это проще всего понять на примере:



$ find /usr/bin -type f -size -50c -exec ls -l '{}' ';'
-rwxr-xr-x 1 root root 27 Oct 28 07:13 /usr/bin/krdb -rwxr-xr-x 1 root root 35 Nov 28 18:26 /usr/bin/run-nautilus -rwxr-xr-x 1 root root 25 Oct 21 17:51 /usr/bin/sgmlwhich -rwxr-xr-x 1 root root 26 Sep 26 08:00 /usr/bin/muttbug

Как видите, find это очень мощная команда. Она «выросла» за годы разработки UNIX и Linux. У find существует много других полезных опций. Вы можете прочитать о них в man-страничке.



locate


Мы уже рассмотрели which, whereis и find. Как вы уже наверно заметили, выполнение find может занять некоторое время, т.к. ей необходимо прочитать каждую директорию в которой выполняется поиск. Оказывается, что команда locate может ускорить процесс использую внешнюю базу данных, генерируемую updatedb (updatedb мы рассмотрим ниже).



Команда locate ищет совпадения любой части пути, а не только самого файла. Пример:



$ locate bin/ls
/var/ftp/bin/ls
/bin/ls
/sbin/lsmod
/sbin/lspci
/usr/bin/lsattr
/usr/bin/lspgpot
/usr/sbin/lsof


Использование updatedb


Во многих Linux системах есть «cron job» для периодического обновления базы. В случае если вызов locate вернул нижеописанную ошибку, вам необходимо запустить updatedb от root'а для генерации поисковой базы:



$ locate bin/ls
locate: /var/spool/locate/locatedb: No such file or directory
$ su -
Password:
# updatedb


Работа программы updatedb может занять некоторое время. Если у вас шумный жесткий диск, вы услышите как он шуршит индексируя файловую систему. :)



slocate


Во многих Linux дистрибутивах, утилита locate была заменена на slocate. Как правило существует также ссылка на locate, так что вам не нужно запоминать, что именно имеется в системе. slocate означает «безопасный locate» (от англ. secure locate — прим. пер.). Он сохраняет информацию о правах доступа в поисковой базе, так что, обычные пользователи не смогут увидеть директории, которые они и так не смогли бы видеть. Используется slocate точно также как locate, но вывод программы может быть различными в зависимости от пользователя ее запустившего.



Перевод выполнил Dmitry Minsky (Dmitry.Minsky@gmail.com)



Продолжение...



Об авторах


Daniel Robbins


Дэниэль Роббинс — основатель сообщества Gentoo и создатель операционной системы Gentoo Linux. Дэниэль проживает в Нью-Мехико со свой женой Мэри и двумя энергичными дочерьми. Он также основатель и глава Funtoo, написал множество технических статей для IBM developerWorks, Intel Developer Services и C/C++ Users Journal.



Chris Houser


Крис Хаусер был сторонником UNIX c 1994 года, когда присоединился к команде администраторов университета Тэйлора (Индиана, США), где получил степень бакалавра в компьютерных науках и математике. После он работал во множестве областей, включая веб-приложения, редактирование видео, драйвера для UNIX и криптографическую защиту. В настоящий момент работает в Sentry Data Systems. Крис также сделал вклад во множество свободных проектов, таких как Gentoo Linux и Clojure, стал соавтором книги The Joy of Clojure.



Aron Griffis


Эйрон Гриффис живет на территории Бостона, где провел последнее десятилетие работая в Hewlett-Packard над такими проектами, как сетевые UNIX-драйвера для Tru64, сертификация безопасности Linux, Xen и KVM виртуализация, и самое последнее — платформа HP ePrint. В свободное от программирования время Эйрон предпочитает размыщлять над проблемами программирования катаясь на своем велосипеде, жонглируя битами, или болея за бостонскую профессиональную бейсбольную команду «Красные Носки».

Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 39

    +1
    За {} спасибо. Всю жизнь xargs использовал.
      +7
      в мане это описано:
      find. -type f -exec file '{}' \;
        +1
        find.unixpin.com/ru/ Вот в помощь. Я много от туда подчерпнул, переодически пользуясь.
          0
          С тем же успехом можно использовать какой-нибудь kfind (если у вас кеды, или любой другой графический интерфейс к find, подходящий для вашего DE)… Веб-интерфейс к командной строке это жесть.
            0
            Это же помошник по команде, а не интерфейс к cli. Первое время у меня попросту небыло времени выучить весь синтаксис find.
              0
              Да я понял, но отличая от gui получаются лишь в том, что тут вам еще надо копировать команду в интерпретатор. Впрочем, конечно, некоторую образовательную функцию оно будет нести, но только в том случае, если пользователь будет вникать в то, что он копирует. В противном случае, лучше просто уж пользоваться gui.
          +2
          та ладно, xargs в 100500 раз вкуснее чем -exec в find
          -exec: каждый раз делает запуск чайлда, иногда это дорого.
          а xargs, запускаемому приложению может передать в качестве аргументов -N имен файлов.

          вот для примера считать md5sum 10000 файлов: что выгодней? делать 10000 вызовов md5sum или один раз md5sum и передать 10000 аргументов?

          даже там, где над каждым найденым файлом нужно выполнять работу отдельным процессом, например пережимание видео — в xargs можно параллельно выполнять по -P процессов (очевиден профит на smp)
            0
            -exec: каждый раз делает запуск чайлда, иногда это дорого.

            По-умолчанию — да. Но если использовать его в форме
            -exec command {} +
            то {} заменится на все найденные файлы, command будет запущена один раз.

            xargs рулит только в случае если нужно сделать что-то вроде
            |xargs -n 1 -P 2 -I '{}' sh -c 'oggenc -Q -q 7 "{}" && rm -fv "{}"'
            т.е. нужно запускать несколько инстансов command параллельно

          0
          Становится интересно ) присоединяюсь к предидущему посту про {} не знал )
          кстати
          $ export PATH=
          А то мб для кого-то не очевидно )
            0
            черт хотелось сделать вот так:
            $ export PATH= < значение >
            тег скушался)
            Ну это вариация на тему export. Я читал не все ваши выпуски, может быть вы уже об этом упоминали…
              0
              $ PATH= < значение >, там было установлено до экспорта в env, а потом просто обновленное значение добавляется в env:
              $ export PATH
                0
                Я понял, что вы имели ввиду, что есть возможность делать это в одну команду, но просто в статье приведен чуть более безопасный вариант.
              0
              Ээээ… куда ставить по этой иерархии неразделяемые несистемные пакеты?
                +4
                Что вы понимаете под несистемными/системными пакетами? Это вам не freeBSD.
                  0
                  Я понимаю /opt и иже с ним.
                  Вы предлагает делить по месту компиляции или степени открытости кода?
                  Т.е. если я собрал пакет сам, то ставлю его в /usr/local?
                  А если тот же пакет получил бинарно — то в usr/opt?
                    0
                    Я ничего не предлагаю. Я говорю по факту имея маны, гугл, и арч с генту под рукой. Не вижу никаких проблем с пониманием куда чего ставить.

                    Когда вы написали про «несистемные» пакеты я вообще то подумал, что вы тонкий freebsd тролль. Ох уж как меня достало это понятие «системы» во фре. Разработчики freebsd считают, что им лучше пользователей известно, какие пакеты считать системными, а какие нет. В итоге мы имеем обязательную систему с громоздким dns-сервером bind на борту (ох да, что же это за система без dns-сервера), парочку ftp серверов (разной степени убогости), сэндмыл и еще кучка всячины. А за тем, что действительно нужно приходится постоянно лазить в /usr/local…

                    Cразу после установки фри выпиливается сендмыл, заменяется на связку exim + dovecot, затем bind меняется на nsd, а фтп валяется в двух экземплярах ненужный, ибо в наш век это жутко устаревший протокол, есть sftp, есть rsync. В итоге в системе остается кучка ненужного хламу, а все нужное живет в /usr/local. Вот такая вот «система» с «системными» пакетами в / и «несистемными» в /usr/local.
                      +1
                      А самое забавное, что фрибээсдэшники этим постоянно хвастаются, что они могут снести /usr/local и у них останется чистая система. Вот только возникает ряд вопросов, во-первых нахрена это делать, во-вторых нахрена нужна эта оставшаяся «чистая» система…
                    0
                    А если через менеджер пакетов — то куда авторы дистрибутива захотели? :)
                    А если у меня пакет свободный, то в usr/opt. Как OpenOffice, например.
                    Но если пакет не свободный, то в /opt — как StarOffice :) :) :)
                    Вы, дорогой товарищ, как-то определитесь :)
                      0
                      /usr/opt — такого вообще нет во многих дистрибутивах.

                      Если пакет имеет закрытый исходный код, тупо бинарники, то в /opt. В противном случае, если неразделяемый, может быть нужен для загрузки то в /, иначе в /usr.

                      В /usr/local ставятся пакеты собранные на дайнной машине, пакеты не из репозитория.

                      Мне определятся не с чем, есть FHS, вполне конкретный документ. Но со временем назначение некоторых папок устарело, и они просто были переориентированы под сегодняшние нужны с минимальными противоречиями.
                  0
                  Кто-нибудь, поясните, пожалуйста, разницу между /opt и /usr/local/.
                    +1
                    В /opt сейчас чаще всего ставится коммерческое ПО. В то время как в /usr/local/ самостоятельно собранное на данной машине.
                      0
                      Наверное стоит поправиться, что речь идет о закрытом ПО. Например, у меня генту благополучно в /opt разместила flashplayer и vitualbox (тот что НЕ open-source edition).
                      0
                      В /opt ставится софт, который тащит за собой всю иерархию. Т.е. /opt/BazBuz/usr, /opt/BazBuz/lib, /opt/Boooo/var и т.д. Каждая софтинка там получает полный комплект нужного, без опасности затереть файлы ОС.

                      Не одобряю, но из всех вариантов самый аккуратный.
                      +2
                      Простите за офтоп, где можно почитать про виндовс консоль?
                        +1
                        cmd or powershell? в гугле полно.
                        НЕ хочу показаться занудой, но я читаю просто help.
                        0
                        Интересно, а кто-нибудь удосужился прочитать упомянутый FHS? Такое ощущение, что его авторы сами для себя пишут — создатели дистрибутивов на него плевать хотели. А уж среди пользователей так и вообще какие-то поверия и мифы ходят :) Даже по обсуждению здесь видно :)
                          0
                          Посмотрите, когда вышел FHS и какой сейчас год. Я не вижу явных противоречий с тем, как сейчас принято в дистрибутивах. Суть одна и та же, только назначения некоторых конкретных папок поменялась с учетом сегодняшних реалий.
                            0
                            В том смысле, что прошло шесть лет, а FHS всё ещё никто не выполняет? Я её сейчас заново просмотрел — всё логично и правильно. Но создатели дистрибутивов упорно игнорируют FHS.
                              0
                              Давайте разберемся. В каком месте вы считаете, что они FHS игнорируют? С ссылкой на конкретной раздел www.pathname.com/fhs/pub/fhs-2.3.html
                              0
                              Ну и прошло то более 6 лет, там в последних релизах не существенные правки. А самое занимательное, что сам редактор FHS в анонсе версии 2.0 пишет:
                              FHS 2.0 is the direct successor for FSSTND 1.2, which is currently implemented by most major Linux distributions (I've lost track, but the list includes Red Hat, Debian, and others. I am interested in hearing from compliant and non-compliant developers).
                        0
                        Ну, так чтобы с ходу, лично у меня такие вопросы:
                        1) Где и у нас нынче размещаются данные для публичных серверных служб — (www, ftp и т.п)? В FHS ясно и понятно написано, про /srv (которая ни разу ни optionаl).
                        2) Бардак c /opt и /usr/bin. В FHS ясно написано — ВЕСЬ дополнительный софт должен устаналвливаться в /opt причём в подкаталоги. Желающие могут создавать символьные ссылки в /usr/bin и т.п. Причём это тоже ни разу не опционально. По факту имеем бардак.
                        3) Многие программописатели до сих пор не удосужились прочитать про раздел /etc и о том, как нужно именовать/располагать файлы конфигурации.
                          0
                          1. в арче, например, в /srv и размещаются
                          $ ls /srv
                          ftp http
                          так уже из коробки, но оба каталога пустые.

                          В генту на ваше усмотрение, можете создать /srv и класть туда. В любом случае, я честно говоря не знаю дистрибутивов в комплекте с которыми уже идут какие-то site-specific данные, это было бы очень странно. Сайты и файло-хранилища вы создаете сами, и можете создать каталог /srv в любом дистрибутиве. Сам дистрибутив ничего туда класть не должен.

                          2. Что такое дополнительный софт для linux? Так весь софт кроме ядра — дополнительный. А если нет, то какой дополнительный? Наверное тот, что не поставляется сообществом, т.е. коммерческий, закрытый.

                          3. Это же уже проблемы отдельно взятых программо-писателей, но на самом деле никакой проблемы в том нет, да и майнтеинеры многих дистрибутивов делают все возможное, чтобы все было в ожидаемых местах с ожидаемым названием.
                            –1
                            2. Именно, что весь кроме ядра. Причём тут открытость/закрытость? И пакеты должны ставится в /opt.
                            3. К сожалению майнтейнеры как-то не слишком убедительно это делают — многие занимают какие-то странные позиции — «наши деды так делали и мы будем».
                              0
                              2. Полный бред. Ваше личное мнение, ничего не имеющие общего ни с реальностью, ни с FHS, ни даже со здравым смыслом. Т. е., по вашему, практически все остальные папки должны оставаться пустыми, включая /etc, /bin, /usr/bin, /usr/lib и т. д.
                                0
                                Т.е. Вы считаете логичным деление места установки программы по степени открытости кода? :) Т.е. StarOffice ставим в одну место, а OpenOffice — в другое? Что делать с программами у которых код частично открыт? Со смешанными лицензиями? И наконец — хит сезона, что делать с программами, которые могут быть и коммерческими и открытыми? Если я использую программу в некоммерческих целях, то ставлю по одному пути, а если в коммерческих, то по другому? :)
                                  0
                                  Это не я предлагаю. Так сделано, так работает, так написано, так принято, в конце-концов так разумно.

                                  И никаких проблем не возникает. Если я ставлю открытую версию VirtualBox, которая OSE, то она ставиться как положено в систему. Если я ставлю проприетарную редакцию, то она устанавливается в opt. У opt есть вполне конкретное назначение. Он нужен для того, чтобы программы установленные в нем, не вызывали конфликтов, не нарушали правил. В /opt у каждой программы своя маленькая песочница, которая не пересекается ни с системой, ни с другими программами. Нельзя задать пути установки и изменить правила именования у многих программ с закрытым кодом, вот поэтому их и помещают в /opt, чтобы им там жилось хорошо, и при этом, они не нарушали равновесия, никому не мешали.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое