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

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

Ты вообще в курсе, зачем /usr/local нужен?)

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

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

// тут я пожалуй соглашусь, но ситуации всякие бывают...

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

> Достаточно написать модуль типа gobohide,

Это вообще не про то. Покури ман, что ли.

скрыть fhs

Зачем?

доделать остальное с помощью линков и mount -o bind.

Через эти костыли и придётся в итоге делать. Потому что выбора нет.

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

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

Зачем? Еще раз, в чем отличие «пакетной системы» от FHS?

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

>> NixOS

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

Ты сделал этот вывод за 7 минут? Круто, чо

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

Надо вам с DRVTiny объединиться и написать идельный пакетный менеджер. Вы будете править миром.

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

Это так удобно - когда человек говорит что-то неприятное, списать это на «обострение».

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

>Это вообще не про то

А про что?

Зачем?

Затем, что fhs больше на структуру БД похожа, чем на иерархию с человеческим лицом

Через эти костыли и придётся в итоге делать

А чего ты вообще хочешь, я не понял? Почему это костыли?

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

> Как и /usr вообще. содержимое /usr вполне могло бы находиться в /home/$USER

Да что мелочиться-то, давай сразу HOME=/ , работа только под рутом, а /home — вообще не нужна.

Гнать вас таких надо метлой обратно в винду, чтоб сидели поуши в своих троянах и общем брадаке на C:\ и не выеживались.

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

>Как и /usr вообще. содержимое /usr вполне могло бы находиться в /home/$USER

1) зачем?

2) как искать свои файлы, если в хомяке вся система, а это тысячи файлов?

3) как рулить правами? Что будет, если сделать rm -rf /home/username?

Зачем все это?

AVL2 ★★★★★
()

Думается всё же, негоже расширять перечень корневых каталогов. Ни при каких обстоятельствах.

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

>1) зачем?

Так смешнее

как искать свои файлы, если в хомяке вся система, а это тысячи файлов?

Почему вся? И каталоги пакетов тебе видеть необязательно

Что будет, если сделать rm -rf /home/username?

Удалится всё, что наустанавливал username

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

>Удалится всё, что наустанавливал username

Вместе с username, конечно

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

> А про что?

Про скрытие каталогов из листинга. Нафейхоа мне их скрывать?

Затем, что fhs больше на структуру БД похожа, чем на иерархию с человеческим лицом

Тебе мозги не той стороной вставили? FHS — это и есть иерархия пространства имён, логичная и продуманная. Но не слишком удобная при управлении пакетами. А вот хранилище типа /packages/${pkgname}/${pkgversion} — это как раз «БД», удобная для управления пакетами, но не пригодная для использования в качестве пространства имен. Виртуализуя же первое поверх второго, мы получаем профиты от обоих и прочие ништяки.

А чего ты вообще хочешь, я не понял? Почему это костыли?

Конкретно в случае с виртуализацией FHS, я хочу иметь возможность поверх одной пакетной базы, построить несколько структур FHS и иметь возможность работать с ними одновременно. Например, дать специализированные пространства имён бинарников и либ разным пользователям. (при этом всё остальное — /media, /var и т.п. должно остаться у них одинаковым)

Сейчас это можно сделать только при помощи чрута и пляски с bind-ами — а они, собственно, не для этого предназначены. Прямым решением была бы либо вставка промежуточного файлового сервиса (на микроядре), либо поддержка вычислимых симлинков (как в драгонфлае). Линукс ни того, ни другого не умеет.

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

>Виртуализуя же первое поверх второго, мы получаем профиты от обоих и прочие ништяки.

Конкретно в случае с виртуализацией FHS, я хочу иметь возможность поверх одной пакетной базы, построить несколько структур FHS и иметь возможность работать с ними одновременно

Нафиг вообще выделять какую-то базовую или корневую структуру?

Тебе мозги не той стороной вставили? FHS — это и есть иерархия пространства имён, логичная и продуманная. Но не слишком удобная при управлении пакетами. А вот хранилище типа /packages/${pkgname}/${pkgversion} — это как раз «БД», удобная для управления пакетами,

По мне так это тебе их не той стороной вставили.

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

>Сейчас это можно сделать только при помощи чрута и пляски с bind-ами

Не нужен chroot. Расщепить систему можно без этого.

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

> Нафиг вообще выделять какую-то базовую или корневую структуру?

Какую базовую? Какую корневую? Есть пространство имен, заданное FHS — его надо виртуализовать. А всё, что не входит в FHS — не надо виртуализовывать. Или же виртуализовать, но иначе. Всё в руках админа.

По мне так это тебе их не той стороной вставили.

Да-да, скажи еще, что все программы надо запускать как /Application/Firefox/bin/firefox, а в PATH затолкать все каталоги вида /Application/*/bin/. А ты точно вменям?

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

>Есть пространство имен, заданное FHS — его надо виртуализовать

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

Да-да, скажи еще, что все программы надо запускать как /Application/Firefox/bin/firefox, а в PATH затолкать все каталоги вида /Application/*/bin/

А зачем их оттуда запускать? Это только для пользователя.

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

> Ты сделал этот вывод за 7 минут? Круто, чо

По существу-то есть что возразить, толстик?

Надо вам с DRVTiny объединиться и написать идельный пакетный менеджер. Вы будете править миром.

Всё ПО уже давно написано, а все идеи воплощены — не бойся, никто ничего не пишет, всё спокойно. Ты главное, не нервничай, а то санитары прибегут.

Это так удобно - когда человек говорит что-то неприятное, списать это на «обострение».

Ок, твой троллинг не обострение — а перманентное состояние. Извини, ошибся поначалу.

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

Да хотя бы оставить в корне минимальную базовую систему, а остальное распихать по хомякам.

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

Но ты можешь хотя бы рассказать такую простую вещь, как нахрена вообще бинарники толкать в хомяк пользователя?

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

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

Каталог = пакет, так понятнее? Где в FHS подобное?

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

>Но ты можешь хотя бы рассказать такую простую вещь, как нахрена вообще бинарники толкать в хомяк пользователя?

Кто сказал про бинарники?

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

> не нужно.

нужно.

нужно.


нужно.


не нужно.


не нужно.


</thread>



+100500

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

> Как и /usr вообще. содержимое /usr вполне могло бы находиться в /home/$USER

Да таких как ты отстреливать надо бы.

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

>Да-да, скажи еще, что все программы надо запускать как /Application/Firefox/bin/firefox, а в PATH затолкать все каталоги вида /Application/*/bin/

Будете сильно удивлены, но в Mac OS X работает и да, там все эти bin не прописаны в PATH. Впрочем, даже если бы и были - не вижу проблемы, при хешировании результатов поиска, которое рпеально есть и сейчас, никаких проблем с производительностью это не создало бы.

DRVTiny ★★★★★
()

> Также обсуждается точное функциональное назначение каталога /srv.

/srv не нужен?

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

>никаких проблем с производительностью это не создало бы

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

Но пока линуксовая инфраструктура до интеграции базы пакетного менеджера с locate и шеллом не доросла еще :(

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

> Ок, твой троллинг не обострение — а перманентное состояние.

Это уже ближе к истине.

Извини, ошибся поначалу.

Не извиню. И кстати, ты не ответил на мой вопрос:

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

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

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

> FHS — это и есть иерархия пространства имён, логичная и продуманная. Но не слишком удобная при управлении пакетами. А вот хранилище типа /packages/${pkgname}/${pkgversion} — это как раз «БД», удобная для управления пакетами, но не пригодная для использования в качестве пространства имен. Виртуализуя же первое поверх второго, мы получаем профиты от обоих и прочие ништяки.

Ты почти точно описал NixOS Store :D

tailgunner ★★★★★
()

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

Сова открывай, медведь пришел!

splinter ★★★★★
()

/home/user/.local/share/ случаем не упразнили?

aedeph
()

Интересно

Интересно,но как новичок я ничего не понял.

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

>Все уже придумано в МакОС.

Ну, кушай свои фекалии, что бы их тут-то размазываешь?

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

>Все уже придумано в МакОС.

Ну, кушай свои фекалии, что бы их тут-то размазываешь?

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

>Так смешнее

теперь понятно, почему предложения с такой мотивацией остаются за порогом?

Почему вся? И каталоги пакетов тебе видеть необязательно

а какой смысл отображать в пространство пользователя то, что ему же потом и не видно?

Удалится всё, что наустанавливал username

а зачем устанавливать софт в хомяк? Во первых, большинство систем, это системы одного пользователя. Во вторых, абсолютное большинство систем, это системы одного администратора. То есть софт ставит (и обновляет!) один человек, а пользуются им все.

Так зачем умножать объемы установок и затраты на обслуживание?

rpm -qa | wc -l

1487

Это вот каждому по полторы тысячи программ в хомяк?

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

>>Каталог /var/run с этого момента становится символической ссылкой на /run

Ну правильно, давайте засрём корень всем подряд!

Дурачок, очень часто /run/ (с tmpfs) нужен ДО того, как смонтируется /var/

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

>Каталог = пакет, так понятнее? Где в FHS подобное?

а как ты предлагаешь раздавать права на эту мешанину данных, библиотек и программ?

Вот к примеру, я могу принудительно снимать права на исполнение с /usr/sharе/doc ибо нефиг программы в документации запускать. А тут?

Собственно, менеджеры пакетов для того и придуманы, чтобы не скатываться к примитивному, насквозь устарелому program files.

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

>Не нужен chroot. Расщепить систему можно без этого.

а зачем ее расщеплять? Какой в этом смысл?

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

>Например, дать специализированные пространства имён бинарников и либ разным пользователям. (при этом всё остальное — /media, /var и т.п. должно остаться у них одинаковым)

а кто будет определять эти спец. пространства? А кто сказал, что /media и /var между этими пространствами совместимы между собой?

Вот откуда вы столько травы берете и трава ли это?!

AVL2 ★★★★★
()

Тред доставляет похлеще вброса Линуса про гном 3. Прямо перепись неадекватов.

По существу - товарищи, предлагающие сделать бинарники в хомяк - катитесь обратно на винду. Фапающие на /Application и иже с ними - в макос. Предлагающие выкинуть local - почитайте man 7 hier. Идиота куски, это unix-way, разбитая по четким правилам система. Хочешь ставить софт - есть пакетный менеджер, который, дебилы, следит за системным софтом.

Кстати, если кто не в курсе, то создание /run форсит ненаглядный леннарт со своим systemd, потому что его поделие без этого работает криво.

liksys ★★★★
()

И еще, gobo-последователи, объясните мне , нахрен вам несколько версий одной и той же софтины? Плюс я понял - быстрый откат на старую версию, но так ли часто этот откат вообще нужен? Существующая структура - сервер->пакетная_система->ось вполне покрывает все потребности. В локальной системе присутствуют только те файлы, которые реально используются, хочешь взять старую версию - сделай даунгрейд пакетным менеджером, он все разрулит. Только не надо мне сказки рассказывать про lib*.so, потому что они разных версий прекрасно живут в /lib и /usr/lib.

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