Библиотека сайта rus-linux.net
Почему разделены директории /bin, /sbin, /usr/bin, /usr/sbin
Оригинал: "Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split"Автор: Thom Holwerda
Дата публикации: 30th January 2012
Перевод: Н.Ромоданов
Дата перевода: февраль 2011 г.
В конечном счете, есть действительно интересные вещи, о которых можно поговорить. Если вы использовали систему UNIX или какую-либо другую систему, производную от нее, вы, вероятно, задавались вопросом, почему в файловой системе присутствуют директории /bin, /sbin, /usr/bin, /usr/sbin. У вас, возможно, даже есть объяснение существования каждого из этих директориев. Однако, дело в том, что все эти объяснения придумали уже после того, как эти директории были созданы. Оказывается, настоящие причины исключительно просты.
Я никогда не делал секрета из того, что я абсолютно ненавижу структуру директориев UNIX. Их названия не описывают их содержимое и часто выбираются абсолютно произвольно; для их правильного понимания требуется учебник, причем в каждом случае приводятся различные рассуждения, связанные с тем, что и где следует располагать. И, к тому же, даже среди дистрибутивов нет согласованности в том, что и где должно находиться.
Это всеобщий и полный кошмар, который коснулся даже моей любимой системы BeOS.
До сих пор все решалось с помощью введения дополнить слоев, скрывающих беспорядок в структуре директориев. Особенно вопиющим в этом отношении является Mac OS X - откройте терминал и в роли пользователя root просмотрите список директориев — здесь еще больший беспорядок, чем в обычной UNIX. Загрузите окно поиска finder и вы увидите совершенно другую структуру директориев.
Это смахивает на покупку красивого автомобиля, двигатель у которого сделан из пирожного и из сгнившей капусты.
Всякий раз, когда я в прошлом жаловался на структуру директориев UNIX, я (и те, кто соглашается со мной) всегда подвергался нападкам, и мне объясняли, почему лучше всего распределять имеющиеся модули по директориям /bin, /sbin, /usr/bin, /usr/sbin и так далее. Самое любопытное, что редко, когда эти объяснения были как-то согласованы друг с другом.
В конце прошлой недели, я наткнулся на обсуждение на сайте HackerNews, дающее некоторое интригующие пояснение того, как появились директории /bin, /sbin, /usr/bin и /usr/sbin . Многие из вас будут удивлены, узнав, что за всем этим разделением нет никакого божественного плана.
30 ноября 2010 года, Дэвид Кольер (David Collier) интересовался в списке рассылки BusyBox, почему "команда kill находится в /bin, а команда killall — в /usr/bin". Он "[не] понимает логики этого". Ответил Роб Ландли (Rob Landley), который предложил интересный взгляд на все это.
Дело в том, что когда в 1971 году Кен Томпсон и Деннис Ритчи переходили с компьютера PDP-7 (на котором они в 1969 году создали UNIX) на PDP-11, они столкнулись с тем, что у них уже был не один жесткий диск размером в 1,5 MB, а два. Удивительно, но теперь у них было безумное количество мегабайт (3 MB). На первом диске находилась операционная системы, а на втором было все, что было связано с пользователями. Второй диск, на котором находились пользовательские данные, монтировался как /usr (/home был добавлен позже).
Центр обработки данных
В какой-то момент операционная система стала слишком большой для первого диска, и ее нужно было расширить на второй диск. В результате Томпсон и Ритчи реплицировали структуру системных директориев (/bin, /sbin, /lib, /tmp и так далее) на второй диск в /usr. Когда они получили третий диск, они перенесли все пользовательские данные из /usr на третий диск, смонтированный как /home.
Это вынудило их предложить ряд правил, например, о том, что команда mount не может быть установлена в /usr/bin,, поскольку команда mount нужна, прежде всего, для монтирования второго диска (/usr).
Лендли объяснял, что "разбиение на директории /bin и /usr/bin (и все остальные) является артефактом этих деталей реализации, относящихся к 1970-м годам, которые десятилетиями сохраняются бюрократами, не желающими задать вопрос о том, зачем это нужно". "Все это потеряло смысл по ряду причин еще до появления Linux".
Затем он продолжает уточнять эти причины. Во-первых, в Linux уже есть временная система, которая решает проблему, связанная с тем, что "некоторый файл необходим раньше, чем другой". Во-вторых, с помощью разделяемых библиотек решаются проблемы, которые были связаны со статической компоновкой (что было нормой раньше, когда был создан UNIX). В-третьих, жесткие диски преодолели рубеж в 100 Мб уже в 1990 году, так что маленький размер диска больше не является проблемой.
Он добавляет, что "бюрократия, работающая со стандартами, такая как Linux Foundation (которая год назад поглотила группу Free Standards Group с ее постоянно увеличивающимся в размере диском стандартов), с удовольствием создает документы и добавляет всякие ограничения, даже не пытаясь сначала понять их смысл". "Мимо их ушей пролетает объяснение, что Кен и Деннис перенесли свою ОС в эквивалентную структуру в home из-за того, что пакет дисков RK05 в PDP-11 был слишком мал".
В некотором смысле, это выглядит как оправдание. Все эти глупые рационализации, о которых все говорят, уже в последние 30 лет бессмысленны, и, разумеется, они никогда не имели смысла в мире Linux.
Аргументация того, что структура директориев UNIX ужасна и настолько беспорядочна, что портит элегантную систему, похожа на попытку убедить укладывать напольную плитки вверх ногами. Те, кто привык к постоянно повторяющемуся ответу, что это все якобы имеет смысл, часто даже отказываются в настоящее время думать о перепроектировании. Т.к. гики от информационных технологий горды и упрямы, мало шансов что что-то поменяется за время моей жизни.
"Я абсолютно уверен, что в busybox двоичные модули просто помещаются туда, куда исторически было принято помещать предыдущие версии этих двоичных модулей. Нет никаких причин дальше поступать именно так. Лично я делаю символические ссылки на /bin, /sbin и /lib и на их эквиваленты в /usr и помещаю их в системе вместе" — подвел итог Лендли, работающий в настоящее время над встроенной Linux — "Те, кто работает над встроенными системами, пытаются во всем разобраться и все упростить ... ".
Послесловие переводчика
Эта небольшая статья интересна не только тем, что в ней делается еще одна попытка критически взглянуть на одну из основ Unix-подобных систем — структуру файловой системы. В ней также делается попытка объяснить причины, почему появился именно такой вариант архитектуры.
Да, действительно, эта структура достаточно сложна и во многих случаях совсем не очевидна для новичка, но важно именно то, что она закреплена как стандарт. Она отработана во многих версиях многих операционных систем и, в среднем, она ведет себя достаточно надежно и имеет приемлемые эксплуатационные характеристики. Благодаря этому нет необходимости каждый раз при создании нового дистрибутива, который, например, может быть специализированным (или, наоборот, расширенным) вариантом некоторого другого дистрибутива, разрабатывать свои собственные решения, которые, даже если они и окажутся лучше уже используемых, могут на практике стать причиной головной боли у администратора системы.
Что же касается конкретных причин возникновения именно такой файловой структуры - возможно, приведенные в статье рассуждения автора достаточно близки к истине. В любом случае, они — интересные.