К вопросу о некоторых аспектах организации файловой системы UNIX/Linux

    1.0 Введение


    После написания предыдущей статьи (Linux: Установка программ не входящих в дистрибутив при помощи менеджера xstow), у меня осталось двойственное впечатление. С одной стороны в статье все правильно, а с другой стороны, отзывы показали, что есть некоторые разночтения в назначении различных частей ФС UNIX. Получилось так, что я дал людям в руки молоток, дал инструкцию по применению молотка, а какие гвозди и куда забивать этим молотком, не сказал. Попытаюсь восполнить этот пробел. В данной статье я попытаюсь, насколько мне это удастся, рассказать, как организована ФС UNIX, зачем это сделано именно это так, для чего и как себя в этой системе вести.



    В дальнейшем в качестве примеров UNIX буду использовать дистрибутив Debian/Ubuntu.

    Как мы знаем из жизни, вся наша жизнь это решение возникающих перед нами проблем, возникновение новых проблем, в том числе и вытекающих из решения предыдущих и так далее, до бесконечности...

    2.0 Проблема: как размещать файлы различных назначений в ОС


    Итак сформулируем первую проблему, как размещать файлы в системе? С одной стороны мы имеем операционную систему и программы, каждая из которых состоит как правило из нескольких, иногда многих файлов. Если с базовыми файлами операционной системы все более менее все понятно, они как правило всегда должны находится в одном и том же месте, то с файлами программ, для которых возможны установка/удаление, ситуация сложнее. С одной стороны, хорошо когда файлы рассортированы по назначению, с другой стороны, удобно, когда деревья директорий файлов программ находятся в директориях, соответствующих программах. Давайте рассмотрим плюсы и минусы данных решений подробнее.

    2.1 Первый вариант: сортировать файлы по пакетам


    Первое, что приходит в голову, давайте файлы ОС разложим по пакетам. Т.е. для каждого программного пакета будет своя директория, в которой будут поддиректории, в которых уже файлы будут разложены так, как это нужно производителю этой программы.

    Плюсы:

    • Каждый производитель раскладывает в своей директории файлы так, как ему нужно.
    • Легко устанавливать/удалять программы, скопировал или уничтожил директорию, и все дела.


    Минусы:

    • Операционная система ищет исполняемые файлы или разделяемые библиотеки по списку, который находится в соответствующей переменной окружения. Например пути к исполняемым файлам перечислены в переменной окружения $PATH. Когда пакетов много, эти списки становятся реально огромными.
    • Есть еще одна веская причина, по которой желательно файлы сходного назначения разных размещать в одних и тех же местах. Дело в том, что из разных соображений, свойства директориев/файловых систем для файлов различных назначений должны отличаться. Это нужно, иногда из соображений безопасности, иногда из соображений оптимальной настройки системы. в UNIX есть возможность монтировать файловые системы в директории. Что это дает? Можно, например, смонтировать директорий для запускаемых бинарников смонтировать в режиме read only, и тогда никакая вредоносная программа туда ничего не сможет записать, а другую директорию смонтировать в режиме запрещающем запуск и тогда никто ничего с этой ФС ничего не сможет запустить. Файлы, которые должны изменяться (например файлы баз данных) располагаем на другой файловой системе, параметры которой можно тоже настроить оптимальным образом.


    2.2 Второй вариант: сортировать файлы по функциям в системе


    Плюсы:

    • Можно оптимально настраивать файловые системы, исходя из функций файлов.
    • Можно оптимально настраивать права доступа на файлы и директории и монтируемые файловые системы.
    • Можно и удобно давать доступ к таким директориям по сети.


    Минусы:

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


    3.0 Решение в UNIX-style


    В UNIX-ах выбрано размещение по второму варианту. Т.е. файлы разных программ с одинаковым функциональным назначением, лежат в одном директории. Например исполняемые файлы разных пользовательских программ лежат в директории /usr/bin.

    4.0 Проблемы, вытекающие из решения в UNIX-style, установка софта


    Проблемы, ясное дело, вытекают из минусов подхода. Это трудности с установкой программ, удалением программ и с определением, какой файл к какой программе относится. Это далеко почти всегда является нетривиальной задачей.

    5.0 Решение проблем: пакетные менеджеры


    В дальнейшем будем называть менеджер пакетов МП.

    Сформулированная в предыдущем разделе проблема в различных дистрибутивах UNIX/Linux решается при помощи работы по установке, удалению и хранению информации об установленном программном обеспечении специальной программе — менеджеру пакетов. В Debian/Ubuntu этим занимается dpkg. Вообще-то это только одна программа из целого набора программ, которые имеют отношение к этому. dpkg, это бэкенд, есть несколько фронтэндов, apt-get, aptitude, dselect, synaptic.

    Что делает МП? По крайней мере в Debian/Ubuntu он занимается следующим:

    1. Установка пакетов.
    2. Удаление пакетов.
    3. Отслеживание зависимостей (при установке пакета вместе с пакетом устанавливать нужные для данного пакета другие пакеты)
    4. Установка пакетов по сети из удаленных репозитариев.
    5. Ведение локальной базы данных установленных пакетов.
    6. Ведение локальной базы данных доступных для установки пакетов в том числе и по сети.
    7. Обновление баз данных при изменении доступных пакетов и/или их версий.
    8. Корректная установка обновлений пакетов.
    9. Апгрейд всей системы.


    Немало, как по вашему? И МП Debian/Ubuntu справляется со всем этим действительно неплохо.

    Сам пакет обычно представляет собой архив файлов, описание пакета с несколькими полями, и скрипты, выполняемые при установке и удалении пакета. В Debian/Ubuntu файл пакета имеет расширение .deb .

    6.0 Проблемы, связанные с пакетными менеджерами


    Как известно, без проблем ничего не бывает. Использование МП тоже не исключение и приносит свои проблемы. Конечно МП решает гораздо больше проблем, чем приносит, но все-таки их нужно знать и с ними бороться. Итак, проблемы:

    1. Зависимости. Это плюс использования МП с одной стороны. С другой стороны отслеживание зависимостей это большая работа мэйнтенеров пакетов. На сегодня Debian входит 25113 пакетов. Одни пакеты требуют обязательной установки других, или наоборот, есть несовместимые пакеты. В результате получается большая и сложная система зависимостей. Все это добро нужно надо проверить.
    2. Иногда встречаются несовместимые комбинации пакетов.
    3. Иногда встречаются всякие хитрые кольцевые зависимости.
    4. В связи с большим количеством пакетов, которые нужно совместить друг с другом, иногда версии пакетов, входящие в дистрибутив устаревают.
    5. Часто в дистрибутиве присутствует ПО не той версии, которая нам нужна.
    6. Несмотря на такое большое количество пакетов, иногда нам нужен софт, которого вообще нет в дистрибутиве.
    7. Мы не можем устанавливать свой софт в директории, где хозяйничает МП, иначе наш софт может вступить в конфликт с софтом, устанавливаемым МП. Проще говоря мы можем затереть файлы, установленные МП, или наоборот.


    7.0 Решение проблем, связанных с пакетными менеджерами, иерархия /usr/local


    В последнее время практически весь нужный софт имеется в дистрибутиве в виде пакетов. Но все-таки рано или поздно как правило каждый пользователь/администратор встречается с необходимостью установки софта, который не входит в дистрибутив. Обычно встречаются такие варианты:

    Проблема 1. Нужно перекомпилировать пакет с другими настройками.
    Проблема 2. Нужного софта нет в дистрибутиве.
    Проблема 3. В дистрибутиве не та версия, которую мы хотим.


    Как быть? Как сделать это с наименьшим риском внести возмущения в работу системы? В наличии имеется несколько вариантов:

    Проблема 1. Решение 1: Перекомпилировать пакет с другими настройками. (Это если нужно пакет с другими настройками). Опасности практически нет, хотя могут измениться зависимости по сравнению с пакетом, откомпилированом в дистрибутиве. Тут уже, ясный перец, за зависимости отвечаете Вы.
    Проблемы 2,3 Решение 2. Собрать собственный пакет и установить в систему.
    Проблемы 1,2,3 Решение 3 Установить софт собранный из исходников в иерархию /usr/local


    С Решение 1 вроде все ясно, давайте рассмотрим подробнее Решение 2 и Решение 3.

    Решение 2: Собрать собственный пакет и установить в систему.


    Плюсы:

    1. Можно использовать все возможности МП, перечисленные в разделе 6.0.
    2. Если пакет предназначен для установки на несколько машин, можно воспользоваться сетевыми возможностями МП, создать свой репозиторий со своими пакетами и устанавливать/обновлять эти пакеты стандартным для МП способом.


    Минусы:

    1. Использование всех или только части возможностей МП требует дополнительных усилий, иногда значительных. Если же ими не пользоваться, то какой смысл в использовании МП?
    2. Если не проверять свой пакет на совместимость, то весьма вероятна ситуация, когда ваш пакет вступит в конфликт с другими пакетами, причем конфликты могут быть самыми неожиданными.
    3. При массовом внедрении такого подхода (создание собственных пакетов), появляется возможность появления в интернете массы плохо оттестированных и плохо совместимых между собой пакетов, как было одно время с с RPM, не знаю, как у них с этим сейчас.


    Debian Policy 2 (Ubuntu как производное от Debian руководствуется им тоже) прямо говорит две вещи:

    • ПО, устанавливаемое локально, устанавливается в иерархию /usr/local.
    • ПО, устанавливаемое локально должно быть в безопасности от переписывания при обновлении системы (имеется в виду обновление через МП).


    Таким образом можно сделать вывод, что для ПО, которого нет в репозитарии, которое устанавливается локально на данную машину, или на небольшое количество машин, стандартный путь — установка в /usr/local.

    Если ПО предназначено для распространения и установки в системы Debian/Ubuntu, лучший путь — упаковка его в .deb пакеты. НО! В этом случае вы отвечаете за зависимости, конфликты и обновления этого пакета.

    8.0 Проблемы, связанные с иерархией /usr/local


    1. Как известно, любое решение приносит новые проблемы. Не исключение и решение, изложенное в предыдущем разделе. Все хорошо, пока мы установили в /usr/local один пакет, как только пакетов становится больше одного, появляется плохо управляемая куча файлов, с проблемами. описанными в разделе 4.0.
    2. Еще одна проблема, это проблема с директорией /usr/local/var Как известно, в директорию /var записываются файлы данных программ, которые могут изменятся во время работы программы (логи, PID-ы файлы БД и так далее). Часто
      /var делают на отдельной партиции, а сейчас у нас получилось, что изменяемые файлы попали в /usr/local/var.


    9.0 Решение проблем, связанные с иерархией /usr/local, возможные воркэраунды


    Решение проблемы 1. описано в моей статье 5, поэтому подробно описывать решение не буду. Вкратце, программы ставятся каждая в свою иерархию в директории /usr/local/stow, а затем, специальны менеджер (xstow), расставляет символьные ссылки на файлы программы.

    Решение проблемы 2. Эту проблему придется решать руками. Если вы воспользовались программой stow, то можно, например, сделать директорию с уникальным именем в иерархии /var, например /var/local_var, а затем сделать ссылки на нее. Но это стоит делать только в том случае, если действительно есть такая необходимость.

    10.0 Иерархия /opt


    В иерархию /opt по Полиси 2 устанавливаю свой софт сторонние производители. Они устанавливают своё ПО в директории вида /opt/package или /opt/provider .

    11.0 Проблемы пользователя, иерархия /home


    Опять же по Полиси 2, файлы пользователей хранятся в иерархии /home, в директориях вида /home/username. Если говорить об установке ПО, то его можно устанавливать и сюда. причем как это делать, отдано на усмотрение пользователя.

    В каких случаях это делать?

    • У пользователя нет прав администратора на компьютере.
    • Временно, "на посмотреть".
    • Собственные скрипты.


    Я обычно использую смесь раскладки файлов "по директориям" и "по пакетам". Для ПО, которое работает постоянно, как правило, это мои скрипты, создаю директории /home/username/bin /home/username/etc /home/username/var. Софт, который просто хочу посмотреть или поиграться просто компилирую в директории /home/username/sw/softname и запускаю просто оттуда.

    12.0 Другие применения иерархии /home


    Часто применяют иерархию /home для размещения файлов, относящихся к крупным задачам, выполняющимся на компьютере. Например, разрабатывается проект с именем projectname. Тогда заводят в системе пользователя с именем projectname и все, к нему относящееся помещают в директорию /home/projectname

    13.0 Другие ОС


    Однажды Вовочкина мама сказала папе:
    "тебе не кажется, что нашему Вовочке уже
    пора рассказать про секс?"
    Папа подумал, и ответил:
    "наверное ты права, только неудобно как-то."
    Мама: "Ну расскажи на примере бабочек."
    Папа позвал Вовочку и говорит:
    "Вовочка, помнишь мы с тобой были в
    публичном доме?"
    "Помню."
    "Ну так вот: у бабочек все точно так же."


    Анекдот


    FreeBSD


    В ОС FreeBSD в принципе все также, с небольшими отличиями. Файлы базовой системы там находятся как и у Linux семейства Debian/Ubuntu в основной иерархии. Бинарным пакетам там соответствуют два понятия, пакеты и порты.

    Пакеты это примерно то же самое, что и пакеты в Debian/Ubuntu. В качестве пакетного менеджера там используется набор команд для работы с пакетами (и портами).

    Порт, это набор вспомогательных файлов, который позволяет скомпилировать и установить исходники в систему. Он позволяет в автоматическом режиме загрузить исходники с носителя (например CDROM) или скачать с интернета, скомпилировать и установить в систему.

    Как пакеты, так и порты устанавливаются в иерархию /usr/local.

    Точно так же, как и в Debian/Ubuntu может встретится ситуация, когда для софта нет ни пакета ни порта. Тогда, естественно, нужно устанавливать софт из исходников. Для этого можно или сделать порт для этого софта, или просто скомпилировать и установить исходники в иерархию /usr/local. Конечно, поскольку в FreeBSD там устанавливается много софта, нужно быть внимательным, т.к. вероятность конфликтов из-за этого возрастает.

    Ну и возвращаясь к методам, описанным в статье 5, думаю, что если Вы не делаете своего порта, для поддержания порядка, можно использовать программу xstow. Хотя у BSD-истов могут быть свои излюбленные методы, неизвестные мне, пусть знающие товарищи меня поправят, если я ошибаюсь.

    Семейство Windows


    В ОС семейства Windows, для размещения софта, как правило применяется подход, когда для каждого пакета ПО — своя иерархия. Наблюдаются некоторые подвижки в сторону раскладки файлов по назначениям, но этому мешают:

    — Отсутствие единого дерева файловой системой (буквы, обозначающие партиции, C:, D: и т.д.).
    — Традиция.
    — Требования совместимости с наработанным софтом.

    Заключение


    Надеюсь статья будет полезной. В принципе можно бы было в другой статье более подробно разобрать назначение других директорий и иерархий ФС UNIX/Linux.

    Список использованных сокращений


    .deb Расширение файлов пакетов ПО для Debian/Ubuntu
    dpkg dpkg — это программное обеспечение, являющееся основой системы управления пакетами в Debian.
    PID Идентификатор процесса
    RPM Red Hat Package Manager — менеджер пакетов Red Hat
    БД База данных
    МП Менеджер пакетов
    ОС Операционная система
    ПО Программное обеспечение
    репозитарии Хранилище софта с доступом при помощи МП
    ФС Файловая система


    Литература


    1. Стандартная иерархия файловой системы Linux (File System Hierarchy Standard)
    2. Filesystem Hierarchy Standard (Дополнение к Debian Policy)
    3. http://ru.wikipedia.org/wiki/RPM
    4. http://ru.wikipedia.org/wiki/Dpkg
    5. Linux: Установка программ не входящих в дистрибутив при помощи менеджера xstow
    6. man hier

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 94

      +8
      я бы наверно переименовал название статьи, все так и это не «организация файловой системы» это скорее организация установки приложений на файловой системе, ну наверно как то так…
      так как тема «организация файловой системы» обычно понимают более глубинный смысл, ну там всякие монирования ФС и т.д.
        0
        Название: О некоторых аспектах
          0
          Название вообще очень понравилось — эдакое предельно-наукообразное =)
            0
            Ну, это типа полушутка. ;)
              +1
              Это типа полуграмотность.
              Потому что можно сказать «К вопросу об организации файловой системы», а можно сказать «О некоторых аспектах организации файловой системы». И то, и другое будет по-русски.
              А «К вопросу о некоторых аспектах организации файловой системы» — это примерно как у советских классиков «наличие отсутствия пропитанных шпал».
                +1
                С шутками вообще сложно все.
          –1
          мне всегда было интересно (как не очень посвященному в вопросах разработки под *n?x человеку) как программисту в этих системах выбирать банальное имя своего исполняемого файла или библиотеки?
            0
            Лучше руководствовать posix (например здесь www.unix.org/single_unix_specification/) и здравым смыслом.
              –1
              оно, конечно, хорошо и правильно — читать man-ы, rfc и прочее… но времени как обычно немного.
              В двух словах можно ответ на мой вопрос?
                0
                Имя должно состоять только из латинницы цифр и. _ —. Если случилось так, что преписывается стандартная утилита, там особые требования. Все.
                  0
                  в общем-то как я и думал — именной ад. Я же как программист не могу знать имена всех утилит в мире nix, согласитесь?
                    0
                    Базовые — в Вашем дистрибутиве. Набираете буквы, жмете ТАБ, и или дописывает, или нет. Еще можно по базе данных пакетов Дебиана искать, там есть практически все. Я это в смысле проверки отсутствия конфликта имен.
                      –1
                      Вы предлагаете у себя на системе установить все доступные в мире пакеты? Это не решение проблемы, это максимум ее отсрочка, согласитесь?
                        0
                        Нет конечно, но основные там уже есть. Тоесть делаете в два шага:
                        1. Проверка в своем дистрибутиве, в установленных пакетах. Прошли проверку, идете к шагу 2.
                        2. www.debian.org ищете по их базе пакетов/файлов. Прошли проверку, на 99% можете быть уверены, что имя годится.
                          0
                          1. дебианом мир nix\bsd\macos\прочих не оканчиватся
                          2. и вообще это не вариант, т.к. всегда есть временной лаг между внесением вашего пакета в пакеты дебиана, и миром.
                            0
                            Да, нет в мире совершенства (С) Лис из маленького принца.
                              +1
                              Вам шашечки или ехать?
                              Полную гарантию, что данное имя не используется для лежащей у кого-то в ~/bin утилиты, вам не даст ни кто.
                              Если вы хотите максимально быстро придумать уникальное имя — придумайте любое и хешируйте его. Наверняка имя 5bb062356cddb5d2c0ef41eb2660cb06 не занято ни для одной утилиты.
                              Для всего остального достаточно проверки наличия этого файла в пакетах для вашего дистрибутива (наверняка везде есть аналоги apt-file), гугла и возможно проверки в дебиановских дистрах, как наиболее больших на данный момент.
                                –1
                                угу, это «не баг, это фича». Ок. Закрыли бесполезную дискуссию.
                                  0
                                  кстати гугл выдал мне: Результаты 1 — 8 из 8 для 5bb062356cddb5d2c0ef41eb2660cb06. (0,09 секунд)

                                  вот и думайте что вы придумали уникальность )
                                  +1
                                  Поставьте в /opt/you_package/bin и радуйтесь
                            +1
                            Их совсем немного, помотрите таки стандарт. Вообще, главное — это здравый смысл.
                              –1
                              habrahabr.ru/blogs/linux/63414/#comment_1760118

                              это здравый смысл в именовании своих программ, но он дает проблемы, увы.
                                0
                                Ну не знаю. Если что-то действительно новое, то здесь есть проблемы. А если Вы что-то совершенствуете, то вполне резонно указать это в имени, например ftp-ng или ftp-ipv6-superbit.
                              –4
                              />
                              * admin
                              * alias
                              * ar
                              * asa
                              * at
                              * awk
                              * basename
                              * batch
                              * bc
                              * bg
                              * break
                              * c99
                              * cal
                              * cat
                              * cd
                              * cflow
                              * chgrp
                              * chmod
                              * chown
                              * cksum
                              * cmp
                              * colon
                              * comm
                              * command
                              * compress
                              * continue
                              * cp
                              * crontab
                              * csplit
                              * ctags
                              * cut
                              * cxref
                              * date
                              * dd
                              * delta
                              * df
                              * diff
                              * dirname
                              * dot
                              * du
                              * echo
                              * ed
                              * env
                              * eval
                              * ex
                              * exec
                              * exit
                              * expand
                              * export
                              * expr
                              * false
                              * fc
                              * fg
                              * file
                              * find
                              * fold
                              * fort77
                              * fuser
                              * gencat
                              * get
                              * getconf
                              * getopts
                              * grep
                              * hash
                              * head
                              * iconv
                              * id
                              * ipcrm
                              * ipcs
                              * jobs
                              * join
                              * kill
                              * lex
                              * link
                              * ln
                              * locale
                              * localedef
                              * logger
                              * logname
                              * lp
                              * ls
                              * m4
                              * mailx
                              * make
                              * man
                              * mesg
                              * mkdir
                              * mkfifo
                              * more
                              * mv
                              * newgrp
                              * nice
                              * nl
                              * nm
                              * nohup
                              * od
                              * paste
                              * patch
                              * pathchk
                              * pax
                              * pr
                              * printf
                              * prs
                              * ps
                              * pwd
                              * qalter
                              * qdel
                              * qhold
                              * qmove
                              * qmsg
                              * qrerun
                              * qrls
                              * qselect
                              * qsig
                              * qstat
                              * qsub
                              * read
                              * readonly
                              * renice
                              * return
                              * rm
                              * rmdel
                              * rmdir
                              * sact
                              * sccs
                              * sed
                              * set
                              * sh
                              * shift
                              * sleep
                              * sort
                              * split
                              * strings
                              * strip
                              * stty
                              * tabs
                              * tail
                              * talk
                              * tee
                              * test
                              * time
                              * times
                              * touch
                              * tput
                              * tr
                              * trap
                              * true
                              * tsort
                              * tty
                              * type
                              * ulimit
                              * umask
                              * unalias
                              * uname
                              * uncompress
                              * unexpand
                              * unget
                              * uniq
                              * unlink
                              * unset
                              * uucp
                              * uudecode
                              * uuencode
                              * uustat
                              * uux
                              * val
                              * vi
                              * wait
                              * wc
                              * what
                              * who
                              * write
                              * xargs
                              * yacc
                              * zcat
                                +1
                                Долго думали перед нажатием кнопки «написать»? Видимо, нет. А стоило бы.
                                  0
                                  Кто же мог знать что хабракат не работает. Теперь и не удалишь.
                            0
                            Отвечу с точки зрения пользователя: имя программы должно быть коротким, если программа в пакете одна, или все программы должны иметь общий префикс, если их много (как, например, было с git-*). Желательно, чтобы имя программы было как-то связано с тем, что она делает. Если это сделать не получилось, имя должно быть запоминающимся, например, из-за оригинальности: не сразу понятно, что guile — это интерпретатор Scheme, а totem — мультимедийный проигрыватель, но со временем запоминается. А если бы назывались inter_sc и playmult, запоминалось бы намного сложнее.
                              0
                              а знаете как я бы назвал свой клиент ftp? а так бы и назвал — ftp… но вот незадача — в системе уже есть файл ftp (да, лежит в другой директории, но это же надуманный пример). А теперь представим что ftp (оригинальный) лежит в /usr/local/bin, куда мне положить свой ftp? А что делать другим программистам, называющих свои ftp-клиенты именем ftp?
                                0
                                Можно посмотреть, как поступают другие. Называют например lftp.
                                С другой стороны, оригинальный ftp лежит в:

                                $ which ftp
                                /usr/bin/ftp
                                


                                Если Вы положите свой ftp в /usr/local/bin, то в большинстве дистрибутивов при вводе команды ftp вызовется Ваш клиент, т.к. обычно в переменной $PATH /usr/local/bin идет раньше, чем /usr/bin

                                А еще можно вызывать программы с полным именем.
                                  0
                                  Называйте хоть троллейбусом, лишь бы конфликта имён не было и с точки зрения пользователя запоминалось. А пользователь может сам через систему альтернатив выбирать, кому называться 'ftp' в его системе:
                                  $ ls -l /usr/bin/ftp
                                  lrwxrwxrwx 1 root root 21 Май  1 16:06 /usr/bin/ftp -> /etc/alternatives/ftp
                                  


                                  Другим программистам можно ничего особого не делать, в дебиане их программу как-то переименуют. Так что лучше сразу называют без конфликта имён.
                                    –1
                                    Библиотеку тоже переименовать вздумают, или имя конфига, или что-то еще? Переименование не вариант и внесет дополнительные сложности и путаницу.
                                      0
                                      Предложите свой вариант решения задачи: как N систем (программистов то есть) без обмена данными друг с другом могут каждая себе выбрать гарантированно уникальное число K_i. А пока почему-то ничего лучше UUID не придумали.
                                        –3
                                        Лично для меня есть два вида решений: приемлемые и неприемлемые.
                                        Для меня приемлемой является система организации имен установленного ПО в windows (компания\продукт\etc.). Она работает (хоть и не всегда, но это лучше чем «все в куче», т.к. в этом случае риск возрастает в разы).

                                        Для меня приемлемая система именования файлов в .NET GAC. Она работает.

                                        Неприемлемо что при назывании бинарников или конфигов мне приходится лезть в гугл\базы имен и т.п.
                                          0
                                          Смотрите статью раздел про директорию "/opt"
                                            +1
                                            Нет, она не работает. Вы не тот usecase сравниваете. Был usecase по поводу запуска из командной строки. В Windows это обслуживается ключом
                                            'HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths', где тоже «всё в куче».

                                            А если вас интересует про запуск из GUI, то бинарник называйте как хотите, всё равно ползователю отображается название из .desktop-файла.

                                            > Неприемлемо что при назывании бинарников или конфигов мне приходится лезть в гугл\базы имен и т.п.
                                            Я вам описал задачу в математических терминах. Приведите её формальное решение.

                                            А ваше решение ничем не лучше (и по сути то же самое). Вот я программист и пишу калькулятор. Как я его назову? calc! Положу, конечно, в %programfiles%\mycompany\calc\calc.exe и обязательно пропишу в реестре в app paths… упс, теперь стандартный калькулятор не запускается (или мой не запускается).
                                              –1
                                              >и обязательно пропишу в реестре в app paths…
                                              как только вам дадут права туда писать, тем более что это не практикуется в windows. Надуманный пример, реальность такова что такого не бывает почти (очень мало ситуаций когда это нужно, и этим реально можно пренебречь).

                                              >Я вам описал задачу в математических терминах. Приведите её формальное решение.

                                              не становитесь занудой, я прекрасно понимаю что решение сложно и врядли осуществимо в реальности. Потому я и говорю лишь о преемственности решения для себя, а не о решении. Если можно уменьшить вероятность возникновения конфликтов — почему это не сделать?

                                                0
                                                > как только вам дадут права туда писать

                                                Дадут сразу же с правами администратора, которые необходимы для установки файлов в %programfiles%. А также для регистрации всякого остального COM (я ведь обязательно хочу сделать ActiveX из своего калькулятора).
                                                  –1
                                                  COM можно регить и для пользователя только, без админ прав.

                                                  В %programfiles%, если настроить также можно будет писать юзеру, без админ-прав.

                                                  И опять же: можно, это не значит что так делают. В nix можно писать и в /boot, но мало кто пишет, не так ли?
                                                    0
                                                    > В %programfiles%, если настроить также можно будет писать юзеру, без админ-прав.

                                                    Насколько я помню, это противоречит guidelines для разработчиков программ Windows (для Designed for Windows XP почти наверняка). И ни один администратор не будет так настраивать систему, это глупо (потому что это Welcome to Windows 95). И поэтому ни один нормальный инсталлятор не будет работать без прав администратора даже если они реально и не понадобятся (да ещё хотя бы потому, что ему msi базу надо записать куда-то).

                                                    Так что давайте не перекручивать факты.

                                                    А чем мой пример calc надуманее вашего ftp я так и не понял. Мы оба воспользовались стандартными средствами системы и получили конфликт имён.
                                                      –1
                                                      А еще почти все инсталяторы (по крайней мере вменяемые) позволяют выбрать каталог установки, так что не перекручивайте факты что вам нужно именно в %programfiles% — туда вас никто не заставляет лезть. Кроме того не вижу ничего криминального в том, чтобы дать пользователю туда писать папки (без прав перезаписи чужих файлов), в подкаталоги-то никто прав не дает, учтите это. Если он и испортит, то только что-то свое.

                                                      В тоже время в nix мне рекомендуется ставиться по вполне определенным каталогам содержащим чужие программы.

                                                      > Мы оба воспользовались стандартными средствами системы и получили конфликт имён.

                                                      И часто вы видели программы, меняющие path в винде?

                                                      На мой взгляд мой пример более реален, нежели ваш. Вот и вся разница. За сим давайте перестанем 8) вы и я прекрасно понимаем друг друга)
                                                        0
                                                        > А еще почти все инсталяторы (по крайней мере вменяемые) позволяют выбрать каталог установки, так что не перекручивайте факты что вам нужно именно в %programfiles% — туда вас никто не заставляет лезть.

                                                        Инсталлятор Office 2007. Написан самим MS. Вменяемее просто и быть не может. Попробуйте поставьте офис к себе в Документы без прав администратора. Я не пробовал, но 100 к 1 что не получится.

                                                        Дело в том, что нужно перестать сравнивать апельсины с яблоками. Изначально был usecase про запуск из командной строки. А для его выполнения в Windows нужно или менять path или добавлять в app paths. Первое редкость, а не делать второго — дурной тон.
                                        • UFO just landed and posted this here
                              +1
                              Спасибо! Однако мне кажется, что проблемы с зависимостями при использовании менеджера пакетов несколько преувеличены. За три года использования Linux, мне так и не удалось с ними встретиться.
                                0
                                Это сейчас научились работать и народу много работает над этим. А раньше было сплошь и рядом.
                                +2
                                > Надеюсь статья будет полезной.
                                А чем она может быть полезной?
                                Обо всём и ни о чём.
                                  0
                                  Все-таки нелишне было бы упомянуть что все рассматривается для Debian/Ubuntu большими буквами, или перенести в Убунтарий. В других дистрибутивах могут быть свои полиси, к слову.
                                    0
                                    В статье есть оговорка, что примеры относятся к Debian/Ubunu. В основном же статья, ИМХО, применима к любому дистрибутиву.
                                    0
                                    man hier для широких масс?
                                      0
                                      О, кстати, добавлю в литературу.
                                        0
                                        тогда уж и pathname.com/fhs/ надо добавить.
                                          0
                                          Это там есть.
                                            0
                                            ТОка сервер уже лежит.
                                              +1
                                              И текст сильно по мотивам, много чего полезного пропущено.
                                                0
                                                Кстати, что именно? Интересно мнение.
                                                  0
                                                  Пропущено про гибридные системы (x86/x86_64) в которых есть lib64 и lib, но может быть lib32 и lib. Каталоги второго уровня выбраны как-то странно есть /var/lock, но ничего не сказано про /var/run и так далее. Кроме того часто встречаются и /srv и /usr/X11R6.
                                                    0
                                                    В FreeBSD cимволическая ссылка /usr/X11R6 -> /usr/local.
                                                    А в Linux'е?
                                                      0
                                                      Счас гляну. Значится так, в Debian-оподобных:

                                                      — Раньше было прямо в /usr/X11R6
                                                      — Теперь раскидано по /usr а из /usr/X11R6 ссылки на директории в /usr
                                                        0
                                                        Где как, в слаке так. Да и во Free так только с с 7-ой версии стало.
                                          +1
                                          а можно как-нибудь ставить пакеты из репозиториев не имея рут доступа, используя тот же синаптик себе в home?
                                            0
                                            ИМХО, если только распаковать пакет, раскидать по домашнему директорию файлы и подкрутить настройки. И не факт, что удасться. Может можно что-нибудь с chroot замутить, но сам я никогда таким не занимался, обещать ничего на могу.
                                              0
                                              Только если вести БД пакетного менеджера у себя же в home.
                                              А для установки наверняка понадобится делать chroot.
                                              А для этого надо быть рутом либо иметь привилегию CAP_SYS_CHROOT.

                                              А чтобы неподготовленная программа заработала без chroot, надо будет чтобы она нашла свои библиотеки (можно добиться установив LD_LIBRARY_PATH), а так же и остальные свои части (тут уже от программы самой зависит).
                                              В целом, проще и правильнее будет её пересобрать из исходников, задав правильный --prefix для configure.
                                              0
                                              Название имеет смысл изменить на что-нибудь вроде «Проблемы файловой организации системы UNIX/Linux», потому как файловые системы это более низкий уровень и к иерархической структуре файлов в системе он имеет отдаленное отношение.
                                              Мельком проскорллил, мои мысли: новичкам наверняка пригодится, а тем кто хоть немного знаком с юникс-лайк системами не стоит тратить время, ничего нового не узнаете.
                                                0
                                                > Название имеет смысл изменить на что-нибудь вроде «Проблемы файловой организации системы UNIX/Linux», потому как файловые системы это более низкий уровень и к иерархической структуре файлов в системе он имеет отдаленное отношение.

                                                Однако же Filesystem Hierarchy Standard примерно про то же самое. Есть просто некоторая двойственность в терминологии.
                                                  –1
                                                  С какой стати Linux внезапно стал UNIX? Отродясь был GNU/Linux (GNU == GNU is Not Unix).
                                                    0
                                                    Это вопрос религии, я в религию не лезу.
                                                      –1
                                                      Это не вопрос религии. Это вопрос правильного называния вещей своими именами и не приписывания им тех свойств, которыми эти вещи не обладают.

                                                      Линуксойды, как правило, любители, «гики». Не обременяющие себя академическими знаниями. UNIX писали учёные-программисты. Linux — студенты. :)
                                                        0
                                                        Да ладно! Неужели?
                                                          0
                                                          Ваша Бздя ничуть не больше Unix, чем Linux, если вы про то.
                                                          И пишут ее те же студенты, а никак не ученые.
                                                        0
                                                        Под UNIX/Linux я имел в виду не то, о чем вы подумали, а всего-лишь UNIX или Linux.
                                                      0
                                                      Спасибо. Помогли разобраться.
                                                      Недавно начал к Дебиану присматриваться и сразу же столкнулся с проблемой, куда ставить программы, которых нет в репах.
                                                      Хотелось бы ещё узнать о других директориях.
                                                        +1
                                                        easylinux.ru/node/170
                                                        ващет, тут вроде все расписано (ссылка из топика)
                                                          0
                                                          Там все написано правильно, но я бы еще осветил причины, почему организовано именно так, а не иначе.
                                                          +2
                                                          Я как раз думаю, писать ли статью о других директориях. Склоняюсь, что надо, хотя доступных материалов много, но мне самому нравится получать информацию в виде статей. Прочитал статью, получил основу. Надо разобраться лучше — смотришь другие материалы. Но общее направление уже понял.
                                                            0
                                                            Программы, собранные вручную и вне системы пакетного менеджмента, в Linux ставятся в каталог /opt или в домашний каталог пользователя.
                                                              0
                                                              Откуда информация?
                                                            0
                                                            ПО, устанавливаемое локально не должно быть в безопасности от переписывания при обновлении системы (имеется в виду обновление через МП).

                                                            Если убрать двойное отрицание, то получается, что «ПО, устанавливаемое локально должно быть в опасности от переписывания при обновлении системы (имеется в виду обновление через МП).». То есть, я ставлю софт в /usr/local/bin, а после apt-get upgrade что-то может слететь? Или я неправильно понял адски завёрнутую фразу?
                                                              –1
                                                              > То есть, я ставлю софт в /usr/local/bin, а после apt-get upgrade что-то может слететь?
                                                              может (это opensource — никто ничего не гарантирует и, по сути своей, не отвечает). вообще при любой установке любого компонента может что-то слететь.
                                                              Но обычно такого не бывает и обновления проходят более-менее гладко… вчера например обновился FF до версии 3.5, половина плагинов не работает 8-)
                                                                0
                                                                > может (это opensource — никто ничего не гарантирует и, по сути своей, не отвечает).

                                                                А в closed-source кто-то что-то гарантирует или отвечает? См. крики людей по поводу того, что после установки SP2 на XP система перестала работать и отнюдь не из-за пиратского софта. Да и вообще MS всю ответственность с себя за любые потери в EULA снимает.
                                                                  –2
                                                                  Есть стратегия развертывания ZeroCopy, она применима и к nix, она дает указанные гарантии и многие продукты так и ставятся…

                                                                  По поводу гарантий, все зависит от заказчика 8) Кроме того, я знаю к кому обратиться за исправлением (телефоны\конкретные люди), а не писать на форумах «боже, что-то случилось и я не могу работать, как все вернуть назад?», что дает мне некое душевное спокойствие.
                                                                    0
                                                                    Странно, тут-то как раз есть кому писать. Ответственности расписаны, email-ы есть. Вы о чем?
                                                                      –1
                                                                      Вопрос приоритетности решений моих проблем в этих двух случаях.
                                                                  0
                                                                  Нет, ничего слететь не может, это я опечатался.
                                                                  0
                                                                  Пардон, моя ошибка, сейчас поправлю. Следует читать:

                                                                  «ПО, устанавливаемое локально должно быть в безопасности от переписывания при обновлении системы (имеется в виду обновление через МП)»

                                                                  Смысл — гарантируется, что МП ничего не делает в иерархии /usr/local

                                                                  Некоторая неуклюжесть из-за того, что это полиси — указания мэйнтенерам пакетов.

                                                                  +1
                                                                  Linux это не UNIX

                                                                  Отрицание UNIX в самой аббревиатуре-акрониме GNU (GNU is Not Unix) — обязательной приставке к слову Linux (GNU/Linux).
                                                                  Это имитация UNIX. Более-менее удачная и только.

                                                                  То, что вы написали о файловых системах, относится только к GNU/Linux, но никак не к UNIX.
                                                                  Например, каталог /usr/local в FreeBSD является штатным каталогом установки приложений из «портов» оригинальных авторских исходников и бинарных пакетов.

                                                                  Идеология FreeBSD, наследника BSD Unix, настолько отличается от Linux, что даже в системных программах (в Linux они называются coreutils) весьма много нюансов.
                                                                    0
                                                                    Успокойтесь, ваше BSD тоже ни разу не тру-юникс, потому что сертификата нету.
                                                                      –1
                                                                      «Без бумажки ты — кака...» :)

                                                                      В исходниках FreeBSD встречается копирайт AT&T. Наличие этих файлов было улажено мировой договорённостью между Novell и CSRG после судебного процесса в 1994 году. Около 70 файлов было оставлено с копирайтом USL. Часть из них переписана.

                                                                      BSD защищала себя в суде c 1992 по 1994 годы от посягательств на свободный код, написанный в университетских стенах энтузиастами.

                                                                      Ядро Linux писалось с нуля в 1991 году, оно начиналось как терминальная программа доступа к университетскому серверу под VMS с использованием инструментов разработки учебной системы Minix. Поддержка POSIX реализована в Linux позднее, чем в BSD-Unix. А нормальный доступ в Интернет и работа с протоколами прикладного уровня в Linux были отлажены только лишь в конце 90-х.
                                                                        +3
                                                                        мне нравится freeBSD и не нравятся только религиозные фанатики, которые гордятся крутыми корнями, и показывают слабый результат в текущем времени.
                                                                          0
                                                                          Почему «показывают слабый результат»? Откуда такая уверенность в превосходстве Linux в текущем времени? Ядро 2.26.30 уже научилось нормально работать с ALSA? GNOME 2.26.3 с критическими исправлениями уже есть в репозиториях популярных дистрибутивов? Firefox 3.5 есть в репозиториях?
                                                                          Как насчёт экспортирования RAW-разделов винчестеров по сети? Какой прогресс в портировании ZFS на Linux? Почему Btrfs 0.19 не поддерживает совместимость «сверху вниз», а только «снизу вверх»? Для Ext4 уже написали онлайновый дефрагментатор, а то люди жалуются на деградацию производительности со временем?
                                                                    +1
                                                                    Добавил в статью, в раздел «Другие ОС» короткий раздельчик про FreeBSD.
                                                                      0
                                                                      Пакеты это примерно то же самое, что и пакеты в Debian/Ubuntu.Несовсем. Пакеты в Debian сильнее гранулированы. Пакеты в FreeBSD практически всегда соответствуют авторской единице инсталляции.

                                                                      Например.
                                                                      Sun JavaSE SDK в репозитории Ubuntu/Debian представлены несколькими пакетами: sun-java6-jdk, sun-java6-bin, sun-java6-demo, sun-java6-source. (Для поддержки русского языка нужно установить sun-java6-fonts, который вне обязательных зависимостей);
                                                                      Sun JavaSE SDK в коллекции портов FreeBSD представлены только одним пакетом: jdk-1.6.0.3p4_11 (порт /usr/ports/java/jdk16), в котором всё это есть.

                                                                      думаю, что если Вы не делаете своего порта, для поддержания порядка, можно использовать программу xstow.
                                                                      Ага.
                                                                      xstow 0.5.1_1
                                                                      Enhanced replacement for GNU stow written in C++
                                                                      There is no maintainer for this port.
                                                                      Any concerns regarding this port should be directed to the FreeBSD Ports mailing list via ports@FreeBSD.org search for ports maintained by this maintainer
                                                                      Port Added: 01 Jan 2003 16:01:06

                                                                      XStow is a replacement of GNU Stow written in C++. It supports all features
                                                                      of Stow with some extensions.

                                                                      XStow as GNU Stow, are programs for managing the installation of software
                                                                      packages, keeping them separate (/usr/local/stow/emacs
                                                                      vs. /usr/local/stow/perl, for example) while making them appear to be
                                                                      installed in the same place (/usr/local).

                                                                      WWW: xstow.sourceforge.net/

                                                                      — AlanE <alane@freebsd.org> 20021231

                                                                      To install the port: cd /usr/ports/sysutils/xstow/ && make install clean
                                                                      To add the package: pkg_add -r xstow
                                                                      www.freshports.org/sysutils/xstow/
                                                                        0
                                                                        > Несовсем. Пакеты в Debian сильнее гранулированы. Пакеты в FreeBSD практически всегда соответствуют авторской единице инсталляции

                                                                        Конечно, они не соответствуют один-в-один, я имею в виду, что они выполняют примерно те же функции, что и пакеты в Debian.
                                                                      +2
                                                                      Хорошая заметка для начинающих. Почему нет?
                                                                        0
                                                                        Ну а чего тогда про MacOS не сказали? Там для пользовательских программ — первый вариант, для системных — второй
                                                                          0
                                                                          Не совсем понял про варианты, если чуть-чуть подробнее растолкуете, добавлю про Мак, просто БСД я когда-то трогал и возился чуть-чуть, а МАКа и близко не видел.

                                                                        Only users with full accounts can post comments. Log in, please.