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)

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

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

Он щас тебе предложит прикрутить какой-нить костыль с контекстами безопасности, которые задает системный администратор с помощью специальной утилиты. Привет венда.

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

> Только не надо мне сказки рассказывать про lib*.so, потому что они разных версий прекрасно живут в /lib и /usr/lib.

libsomething.so.1.1 и libsomething.so.1.2 живут не то, чтобы очень хорошо.

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

> libsomething.so.1.1 и libsomething.so.1.2 живут не то, чтобы очень хорошо.

Слинковаться с правильной версией, ld все разрулит. Если нет, ткни носом, плз, где я ошибаюсь.

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

>Версия одна, библиотеки разные. Проблема.

Библиотека одна - libsomething.so.1 - именно это имя используется при загрузке.

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

>> libsomething.so.1.1 и libsomething.so.1.2 живут не то, чтобы очень хорошо.

Слинковаться с правильной версией, ld все разрулит.

Ты слинковал программу с libsomething.so.1.1, линковщик прописал soname libsomething.so.1; потом libsomething обновился до версии 1.2, в которой что-то исправили или сломали (но soname остался libsomething.so.1), и твоя прога не работает; если найдется программа, которой нужна именно libsomething 1.2 (и она не работает с более ранней версией из-за багов или фиксов), ты в тупике.

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

>>Версия одна, библиотеки разные. Проблема.

Библиотека одна

А, ну как скажешь.

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

>обновился до версии 1.2, в которой что-то исправили или сломали

Если сломали - беги в багзиллу. Потому как ломание обратной совместимости API/ABI без смены сонейма запрещена.

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

>> обновился до версии 1.2, в которой что-то исправили или сломали

Если сломали - беги в багзиллу.

А еще нужно написать в Спортлото

Потому как ломание обратной совместимости API/ABI без смены сонейма запрещена.

Исправление ошибок - тоже?

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

Ситуацию понял, спасибо.

А разве по умолчанию будет искаться не полное совпадение имени библиотеки? Если будет найдет object для libsomething.so.1.1, то ld будет использовать именно его, нет?

По идее, проблема решается существованием пакета libsomething с либой последней версии с /lib/libsomething.so{,1.2} с soname на libsomething.so.1 и еще одного пакета libsomething1.1 со старой версией.

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

>Исправление ошибок - тоже?

Исправление ошибок (как и добавление функциональности в библиотеку, в т.ч. разширение API) без ломания обратной совместимости API/ABI можно и нужно делать без изменения сонейма. //KO

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

PS: Подход уродский, но это только на экстренный случай.

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

> А разве по умолчанию будет искаться не полное совпадение имени библиотеки?

По умолчанию ищется so-файл, имя которого совпадает с soname библиотеки. В нашем случает soname - libsomething.so.1

По идее, проблема решается существованием пакета libsomething с либой последней версии с /lib/libsomething.so{,1.2} с soname на libsomething.so.1

Ты предлагаешь выпустить библиотеку с новым soname только для того, чтобы исправить описанную проблему? На это никто не пойдет.

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

Это лучше, чем старые либы без апдейтов :}

Deleted
()

Так или иначе, но это ещё одна причина переходить на Plan 9.

anonymous
()

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

Какую лажу опять придумали для игр линуксоиды:( Намного лучше все игровые ресурсы, библиотеки и прочие бинарники размещать в /usr/share/собственный_каталог_игры_для_всего_что_надо. Для игры несколькими учётными записями существуют каталоги /home/user/.каталог_игры. А в /usr/bin если по уму, то надо класть лишь исполняемый скрипт, который запустит игру. Опера нормально запускается через баш скрипт и игры так тоже могут.

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

> а кто будет определять эти спец. пространства

Админ при помощи пакетного менеджера.
Грубо говоря, будет что-то типа:

# apt-ns create testing1 --clone base
# apt-ns create testing2 --clone base
# apt-get install kde4.6 --namespace testing1
# apt-get install kde4.7 --namespace testing2
# chrootns testing1
# su -l username
username:~$ юзаем kde 4.6
.
.
.
username:~$ ^D
# chrootns testing2
# su -l username
username:~$ юзаем kde 4.7



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


Админ сказал. Если /var потребуется другая, значит, её тоже виртуализуем.

Тебе что, никогда не приходилось плясать с chroot, bind-ами и установкой пакетов в chroot-системе, чтобы создать какое-нибудь тестовое окружение? Уже хотя бы для автоматизации такой задачи стоит создать пакетник, который всё это будет уметь сам. Тем более, что этим его ништяки не ограничиваются: можно создать отдельные наборы установленных программ для разных юзеров, можно без перекомпиляции поставить и заставить работать конфликтующие пакеты, можно использовать пространства имён для атомарного отката между обновлениями системы. Куча преимуществ.

Ты мне напоминаешь такого чувака, который возмущается «пакетные менеджеры — зло! всю жизнь софт ставили при помощи ./configure && make && make install, и всё работало! а кто сказал, что пакеты, устанавливаемые менеджером совместимы? Машина не заменит человека! Только хардкор, только ручная установка!»

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


Это хорошие, годные грибы.

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

поправка: c:\users\ D&S выглядело убого даже для винды

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

> Если сломали - беги в багзиллу. Потому как ломание обратной совместимости API/ABI без смены сонейма запрещена.

Мне не нужна рабочая система через 2 недели. Мне нужна рабочая система здесь и сейчас.

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

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

А как ты раздаешь права на файлы в FHS?

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

Точно. А теперь давай ты сделаешь следующий шаг и осознаешь, что менеджеры пакетов можно использовать и не для одного пространства имён, а для нескольких.

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

Я и не несу пургу. И я знаю, чем /bin отличается от /sbin. И не вижу никакого смысла разделять их содержимое. Все равно «обычный» пользователь частенько выполняет утилиты из /sbin.

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

Если слово «ориентировать» вызывает у вас сортирные ассоциации то вам к доктору.

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

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

Совершенно не в курсе. Не нужен он!

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

На сервере вы тем более никогда не переполните корень (если, конечно, не будете в него пихать /tmp, /var, всякие пользовательские данные и т.п.) Для сервера 1ГБ по уши достаточно.

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

> Пофиг на «засрём корень», а вот то что / в ro не смонтируешь это плохо.
/run предполагается делать в tmpfs вроде как

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

/packages/${pkgname}/${pkgversion}

Один я подумал про /usr/portage/?

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

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

> Один я подумал про /usr/portage/?

Ну и при чем тут портаж?

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

Приложениям не нужны ${pkgname}/${pkgversion}. Приложение должно видеть FHS. ${pkgname}/${pkgversion} для _хранения_ _пакетов_.

Я может пишу не по-русски?

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

Ну и при чем тут портаж?

Там вроде как раз ${pkgname}/${pkgversion}(хотя последнее там только в окончаниях имен ебилдов). Хотя пакетный менеждер один фиг заводит себе БД. Если это аналог файловой системы, почему она должна виртуализироваться и быть в «корне»? Можно же, как в генте, положить в один из каталогов. Если бы сейчас шел 92 год и они бы разработали стандарт каталогов пакетного менеджера, то современного разброда бы не было. Может, даже только одна система управления пакетами бы выжила. А теперь уже ничего не изменить

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

> Совершенно не в курсе. Не нужен он!

Ты просто не знаешь, зачем он нужен :)

На сервере вы тем более никогда не переполните корень (если, конечно, не будете в него пихать /tmp, /var, всякие пользовательские данные и т.п.) Для сервера 1ГБ по уши достаточно.

Добавь веб-сервер в список к тому десктопу, ага.

«Мне не нравится, что бинарики лежат в двух папках а не одной, правда я этого не замечаю потому что есть $PATH, НО Я ВСЁ РАВНО НЕДОВОЛЕН!» - только ради этого глупо жертвовать гибкостью такой иерархии файлов, какая имеется сейчас.

И вообще, если не нравится FHS. Будь мужиком, создай симлинки.

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

Ты шо тугой такой? он тебе про иерархию говорит. В принципе да, иерархия могла бы выглядеть, как дерево портежей, это намного удобнее.

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

А в чем разница? Пакетный менеждер работает с упорядоченным набором сущностей, каждая либо из которых знает, где лежат исходники/бинарники в случае source-based дистра, либо является совокупностью метаданных и самой информации

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

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

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

> Файловой системы. То, что ты предлагал в стиле ${pkgname}/${pkgversion}

Это вообще не иерархия, это просто пакеты. Концептуально, там может быть хоть ${pkgname}/${pkgversion}, хоть $(md5sum pkg.tar.gz) — главное, чтобы содержимое отдельных пакетов лежало в отдельных каталогах, идентифицируемых пакетным менеджером.

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

>Это вообще не иерархия

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

Я тебя что-то не пойму. Куда ты хочешь впиливать эти «отдельные каталоги», если не в иерархию?

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

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

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

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

>Опиши уже своё видение правильной организации пространства имён, чтобы разговор стал предметным

Обязательно, но несколько позже.

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

> Куда ты хочешь впиливать эти «отдельные каталоги», если не в иерархию?

В иерархию, да. В FHS. Установка пакета в пространство имён сводится к размещению симлинков на файлы пакета. Удаление — удалению симлинков. (Технически это могут быть и несимлинки, а какие-нибудь юнионы или другие средства, концептуально это не важно, опять же.)

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

>В иерархию, да. В FHS. Установка пакета в пространство имён сводится к размещению симлинков на файлы пакета. Удаление — удалению симлинков

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

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

круто, конечно. А как же «слоты» в той же генте? Кажется, слишком много телодвижений для простого назначения разных версий программ разным пользователям. Проще тогда каждому по вирутальной машине выделить:)

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

Будь мужиком, создай симлинки.

Не годится: пакетный менеджер не будет их обновлять.

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

> Не далее, как вчера, ты проклинал линки, называя их костылями. Я уже окончательно запутался.

Я более говорил о bind + chroot, называя их костылём для виртуализации пространств имён, нежели о симлинках. Когда мы говорим о реализации, это костыли. Но более подходящих средств у нас под Linux нет. Хотелось бы видеть хотя бы поддержку вычислимых контекстно-зависимых симлинков, чтобы избежать кучи bind-ов.

Но когда мы говорим о самой концепции, нам не важно, как именно будет технически собираться пространство имен.

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

>А как ты раздаешь права на файлы в FHS?

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

Точно. А теперь давай ты сделаешь следующий шаг и осознаешь, что менеджеры пакетов можно использовать и не для одного пространства имён, а для нескольких.


Да бы бы смысл. Чрут в rpm есть c незапямятных времен и даже используется, но нафига это в обычной системе?

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

> А если там мешанина, то и права получаются запутанными.

Схренали в FHS будет мешанина? Правда, ты не сможешь назначить отдельно права те элементы, которые являются симлинками, но — специально для такого случая можно даже предусмотреть установку не в виде симлинков/хардлинков, а копированием файлов, как в обычных пакетниках. Такой частный случай работы, сводящий «умный» пакетник в «классический». Хотя я правда не знаю, заем это может понадобиться. На всё, что лежит в /lib, /*bin, /usr, нет никакого смысла менять права — это же просто код + вспомогательные ресурсы.

но нафига это в обычной системе?

Например, я тестирую сборку пакетов в чистой системе.

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

> Админ при помощи пакетного менеджера.

Грубо говоря, будет что-то типа:

# apt-ns create testing1 --clone base
# apt-ns create testing2 --clone base
# apt-get install kde4.6 --namespace testing1
# apt-get install kde4.7 --namespace testing2

а при помощи ФС со снапсшотами на запись эту проблему решить можно? типа ZFS или BTRFS?

псевдо-команды: # create snapshot test1 --clone base # create snapshot test2 --clone base # chfs test1 # apt-get install kde4.6 # chfs test2 # apt-get install kde4.7

тогда и пакетный менеджер работает как сейчас и у вас реально разные окружения - test1 & test2

PS с снапшотами на запись не работал.

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