LINUX.ORG.RU

Что нового будет в третьей версии Filesystem Hierarchy Standard?

 


0

1

На сайте linux.com появилась небольшая статья, описывающая грядущие изменения в стандарте отвечающем за иерахию файловой системы в Unix-системах.

Коротко о планируемых изменениях в Filesytem Hierarchy Standard 3.0:

  • Появление каталога /run для размещения там необходимых при запуске системы файлов, таких как PID процессов или информацию о сессиях пользователей. Каталог /var/run с этого момента становится символической ссылкой на /run. Причиной побудившей к такому шагу является то, что каталог /var, как правило, выносится на отдельный раздел, так как там хранятся журналы, кэш почтовых и веб-серверов, который монтируется при загрузке в последнюю очередь. Впрочем, дискуссия касательно данного решения всё ещё идёт.
  • Игры планируется размещать по следующей схеме: /usr/bin для бинарных файлов, /usr/share для ресурсов игры и /var/lib для тех компонентов, которые должны быть доступны на случай наличия нескольких учётных записей в системе. Старая схема предполагала размещение игр и их компонентов в отдельных каталогах /usr/games и /var/games.
  • Директория для SELinux из корневого каталога /selinux будет перемещёна в /sys/fs/selinux.
  • Директории для старых версий X-сервера, вроде /usr/X11R6 и прочих ранее используемых мест в файловой системе будут удалены из стандарта за ненадобностью. Связано это с тем, что x.org прочно вошёл в жизнь как пользователей, так и администраторов unix-подобных систем, поэтому надобность в поддержке в старой версии подсистемы X отпала. Из старых, но до сих пор не вошедших в стандарт вещей, в настоящий момент обсуждается внедрение отдельных каталогов для 32-х и 64-х разрядных библиотек (/lib и /lib64 соответственно). Что позволило бы использовать дистрибутивы Linux на компьютерах со смешанной архитектурой. Проблема была поднята разработчиками дистрибутива Debian. Интересующиеся подробностями технологии могут сходить на нужную wiki-страницу.

Такой же нерешённой проблемой остаётся определение размещения специализированных директорий, необходимых для хранения конфигураций рабочего пространства пользователя в графических окружениях вроде KDE. Также обсуждается точное функциональное назначение каталога /srv.

Ещё одно обсуждение касается разделения каталога /var на несколько субдиректорий для разделения данных разного рода. К примеру, сетевые каталоги вынести в /export.

С принятием новой версии стандарта планируется оживить дискуссию со всеми участниками Unix-мира (например, разработчиками BSD-систем), которые практически отстранились от участия в разработке стандарта с момента утверждения FHS версии 2.3.

новость взята с linux.ru

>>> Подробности

★★★★★

Проверено: Dimez ()
Последнее исправление: JB (всего исправлений: 14)

Ответ на: комментарий от Eddy_Em

Почему же дурость? Вполне разумно разделить приложения и библиотеки на две категории. Нужные и «не примонтировалось - да и хрен с ними». Да и полезность /usr/local в дистрибутивах с пакетными менеджерами сложно переоценить.

melkor217 ★★★★★
()
Ответ на: комментарий от melkor217

Да и полезность /usr/local в дистрибутивах с пакетными менеджерами сложно переоценить.

Не вижу никакой полезности, кроме необходимости прописывать везде в PATH еще и /usr/local/bin.

Жесткие диски сейчас такие, что под корень можно смело выделить гигабайт 20, тогда уж точно никогда не переполнится и все исполняемые файлы можно будет сваливать в /bin. Естественно, для /var, /home и пользовательских данных выделять отдельные разделы.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

>Зачем разносить все по разным директориям? В стройной системе LD_LIBRARY_PATH=/lib:~/lib, а PATH=/bin/:~/bin

Все остальное - дурость.

иди уж до конца. В стройной системе есть /

все остальное лишнее.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

Ну, это перебор уже будет :)

Все-таки, для разнородных файлов стоит выбрать общие хранилища: все общесистемные настройки - в /etc, все общесистемные исполняемые файлы - в /bin, общесистемные библиотеки - в /lib, файлы ресурсов (значки, .rc и т.п.) - в /usr, профили пользователей - в /home, данные пользователей - в /data. Ну и опционально - для музыки, фильмов и т.п. (/music /cinema ...)

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

> все общесистемные исполняемые файлы - в /bin, общесистемные библиотеки - в /lib

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

все общесистемные исполняемые файлы - в /bin, общесистемные библиотеки - в /lib, файлы ресурсов (значки, .rc и т.п.) - в /usr

Я бы сделал так — вся система в /usr: в /usr/bin — исполняемые файлы, в /usr/lib — библиотеки, в /usr/share — ресурсы.

/bin,/sbin и /lib — симлинки на /usr/bin и /usr/lib для совместимости.

Ну и опционально - для музыки, фильмов и т.п. (/music /cinema ...)

Для этого есть подкаталоги /media.

geekless ★★
()

> Игры планируется размещать по следующей схеме: /usr/bin для бинарных файлов, /usr/share для ресурсов игры и /var/lib для тех компонентов, которые должны быть доступны на случай наличия нескольких учётных записей в системе. Старая схема предполагала размещение игр и их компонентов в отдельных каталогах /usr/games и /var/games.

Вот это правильно. Никогда не понимал чем игры принципиально отличаются от остальных программ.

drull ★☆☆☆
()

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

d9d9 ★★★★
()
Ответ на: комментарий от d9d9

> Конечному пользователю на саму систему глубоко насрать, так что нечего мозолить глаз.

И не мозолит. Пользователь обычно из своего хомяка не вылазит.

drull ★☆☆☆
()
Ответ на: комментарий от geekless

> Для этого есть подкаталоги /media.

/media для removable

А /mnt для temporary. Поэтому подобный общий хлам вообще непонятно куда пихать. Тоже в корень, наверное.

anonymous
()
Ответ на: комментарий от drull

> И не мозолит. Пользователь обычно из своего хомяка не вылазит.

Вопрос в том - что решает размазывание системы по руту, что нельзя решить спрятав весь этот каличный мусор на один уровень глубже в папку, например, .os?

d9d9 ★★★★
()

Все обсуждают, как мудрее расположить файлы, как будто это даст что-то принципиально иное. Какая-то фигня творится.

Un
()
Ответ на: комментарий от anonymous

> /media для removable

Дык а если у меня любой винт потенциально removable? :)

На самом деле использовать media вполне логично — там монтируются разделы по их меткам, вот и отлично.

geekless ★★
()
Ответ на: комментарий от Un

> как будто это даст что-то принципиально иное

Даст спокойствие и умиротворение.
Когда базовые вещи сделаны через *опу, то что говорить о более сложных.

d9d9 ★★★★
()

в общем, берите от Mac OS X - вот будет дело

например, есть MoonOS - Ubuntu и идеальной иерархией файловой системы

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от d9d9

Базовые вещи просто придуманы так. Концепция «файл - программа» убога.

Un
()
Ответ на: комментарий от geekless

На самом деле использовать media вполне логично — там монтируются разделы по их меткам, вот и отлично.

У кого как. У меня, например, для сменных устройств создаются директории вида файловая_система-устройство, например, reiserfs-sdj1.

Eddy_Em ☆☆☆☆☆
()

И в очередной раз все сломают....
Я даже не представляю кол-во софта,которое придется переписывать с новыми путями(ибо я уверен что они еще и в переменных окружения все переименуют,будет не HOME а HOME_KDE и HOME_MAIN...и тдтп....)

Странное у них там занятие...

anonymous
()
Ответ на: комментарий от anonymous

>Я даже не представляю кол-во софта,которое придется переписывать с новыми путями

Я даже не представляю, что надо делать с говнокодерами, которые хардкодят пути в программах

Un
()

/srv.я вообще у себя дома на отдельную партицию вынес

kto_tama ★★★★★
()
Ответ на: комментарий от uju

где ты был когда это в федоре предложили?

Thero ★★★★★
()
Ответ на: комментарий от geekless

окей, я к тому что это несущественно

Thero ★★★★★
()
Ответ на: комментарий от geekless

Нужно нормальное отображение пакетной структуры на традиционную FHS, причём пакетная должна быть основной, а FHS - просто одним из возможных виртуальных отображений. Так уже давным-давно сделали в QNX, потому что этот вопрос решала одна компания, а не коллективный разум. Коллективный разум OpenSource неэффективен при решении каких-то вопросов творческого плана: у каждого своё видение, каждый тянет в свою сторону, а в итоге самые смелые идеи делятся на нулть сразу и в лучшем случае мы получим добавление /srv и /run в корень, что абсолютно ничего не изменит, но зато и не встретит отчаянного сопротивления, потому что всем по барабану.

DRVTiny ★★★★★
()
Ответ на: комментарий от d9d9

>Вопрос в том - что решает размазывание системы по руту, что нельзя решить спрятав весь этот каличный мусор на один уровень глубже в папку, например, .os?

Ну какой os, надо linux. C:\LINUX, а чо, виндузятникам так привычнее

goingUp ★★★★★
()
Ответ на: комментарий от DRVTiny

>Коллективный разум OpenSource неэффективен при решении каких-то вопросов творческого плана: у каждого своё видение, каждый тянет в свою сторону, а в итоге самые смелые идеи делятся на нулть сразу и в лучшем случае мы получим добавление /srv и /run в корень, что абсолютно ничего не изменит, но зато и не встретит отчаянного сопротивления, потому что всем по барабану.

Какое точное наблюдение. И какие глубокие метафизические последствия - рациональный склад ума стоит на месте, прогресс двигают шизофрении.

Un
()
Ответ на: комментарий от DRVTiny

> Коллективный разум OpenSource неэффективен при решении каких-то вопросов творческого плана: у каждого своё видение, каждый тянет в свою сторону, а в итоге самые смелые идеи делятся на нулть сразу

Ты песец какой нытик.

tailgunner ★★★★★
()
Ответ на: комментарий от geekless

> Дык а если у меня любой винт потенциально removable? :)

На самом деле использовать media вполне логично — там монтируются разделы по их меткам, вот и отлично.

В стандарте явно указано — removable like CD and USB. Обычные винты сюда не катят. Тем более что что туда и как монтируется очень варьируется даже по дистрам.

anonymous
()
Ответ на: комментарий от DRVTiny

> Нужно нормальное отображение пакетной структуры на традиционную FHS, причём пакетная должна быть основной, а FHS - просто одним из возможных виртуальных отображений.

Согласен.

Так уже давным-давно сделали в QNX

Там это решается методами симлинков или при помощи более других средств?

Просто все прекрасные мечты разбиваются о суровую реальность несовершенства VFS в линуксе. Скажем, я хотел бы иметь возможность запустить процесс с частично переопреденным адресным пространством — например, в одном процессе у меня /usr пусть указывает на /usr1, а в другом — на /usr2. На микроядре можно эту задачу решить просто и красиво, подсунув процессу промежуточный файловый сервис, а на линукс — надо совершать магический танец с mount-bind-ами и чрутом.

Коллективный разум OpenSource неэффективен при решении каких-то вопросов творческого плана

Ну почему же. Можно собрать единомышленников и запилить новый пакетный менеджер.

а в итоге самые смелые идеи делятся на нулть сразу и в лучшем случае мы получим добавление /srv и /run в корень, что абсолютно ничего не изменит, но зато и не встретит отчаянного сопротивления, потому что всем по барабану.

/run — это полезное добавление к FHS. В любом случае.

geekless ★★
()
Ответ на: комментарий от anonymous

> В стандарте явно указано — removable like CD and USB. Обычные винты сюда не катят. Тем более что что туда и как монтируется очень варьируется даже по дистрам.

Ну в данном случае, тем хуже для стандарта.

geekless ★★
()
Ответ на: комментарий от geekless

Согласен, что в QNX сделано не симлинками и есть понятие файлового сервиса. Непонятно только,что принципиально мешает в Linux сделать аналог?

DRVTiny ★★★★★
()
Ответ на: комментарий от geekless

>> Так уже давным-давно сделали в QNX

Там это решается методами симлинков или при помощи более других средств?

На микроядре можно эту задачу решить просто и красиво, подсунув процессу промежуточный файловый сервис

На каком микроядре ты убедился в «простоте и красоте» такого решения?

Коллективный разум OpenSource неэффективен при решении каких-то вопросов творческого плана

Ну почему же. Можно собрать единомышленников и запилить новый пакетный менеджер.

Более того - его уже запилили. Пока ты мечтал о микроядрах и ниасиливал namespace'ы.

tailgunner ★★★★★
()

Такое впечатление, что в этом треде собрались люди, которым FHS ежеминутно мешает жить. Столько бреда и ненависти.

anonymous
()
Ответ на: комментарий от DRVTiny

> Непонятно только,что принципиально мешает в Linux сделать аналог?

Торвальдс же.

geekless ★★
()
Ответ на: комментарий от geekless

>> Более того - его уже запилили.

Ну блесни что ли знанием

NixOS

о зеленый

Зеленый здесь ты - как в смысле нубства, так и в смысле троллинга.

tailgunner ★★★★★
()
Ответ на: комментарий от geekless

>Просто все прекрасные мечты разбиваются о суровую реальность несовершенства VFS в линуксе. Скажем, я хотел бы иметь возможность запустить процесс с частично переопреденным адресным пространством — например, в одном процессе у меня /usr пусть указывает на /usr1, а в другом — на /usr2. На микроядре можно эту задачу решить просто и красиво, подсунув процессу промежуточный файловый сервис, а на линукс — надо совершать магический танец с mount-bind-ами и чрутом.

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

А во вторых, никто же не мешает точно также запускать свой промежуточный файловый сервис и подсовывать его процессам.

В чем суть стенаний?

AVL2 ★★★★★
()
Ответ на: комментарий от DRVTiny

>Нужно нормальное отображение пакетной структуры на традиционную FHS,

А в чем отличие «пакетной структуры» от «традиционной FHS»?

AVL2 ★★★★★
()
Ответ на: комментарий от tailgunner

> NixOS

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

Вердикт: закопать труп и больше не раскапывать.

Зеленый здесь ты - как в смысле нубства, так и в смысле троллинга.

У вас напару с мегабаксом обострения что ли начинаются? Или вы клоны друг друга?

geekless ★★
()
Ответ на: комментарий от AVL2

> А во вторых, никто же не мешает точно также запускать свой промежуточный файловый сервис и подсовывать его процессам.

Где, в Hurd-е? Ну да, не мешает, только вот он не допилен. А так — ты малость ядром ошибся.

geekless ★★
()
Ответ на: комментарий от geekless

>Где, в Hurd-е? Ну да, не мешает, только вот он не допилен. А так — ты малость ядром ошибся.

в линуксе.

напиши свою фс чере fuse или напрямую, модулем, монтируй и рули своими отображениями. В чем проблема-то?

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

Правда есть в этом минус - такой модуль будет работать со скоростью накопителя, а не 20килобит/сек, как в микроядре.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

> напиши свою фс чере fuse или напрямую, модулем, монтируй и рули своими отображениями. В чем проблема-то?

Проблема в том, что это давно и так должно быть из коробки. Если бы архитектура ядра была вменяемой.

geekless ★★
()
Ответ на: комментарий от AVL2

Хотя, я тоже не пойму, в чём проблема. Достаточно написать модуль типа gobohide, скрыть fhs и доделать остальное с помощью линков и mount -o bind.

Un
()
Ответ на: комментарий от Un

>Для корня? Петросян.

а что? в чем проблема?

AVL2 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.