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

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

IZen , залогинтесь

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

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

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

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

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

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

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

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

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

> все общесистемные исполняемые файлы - в /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.

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

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

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

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

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

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

/media для removable

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

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

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

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

> /media для removable

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

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

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

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

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

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

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

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

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

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

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

да ты я погляжу еретик!

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

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

ZFS всех зарулит :-)

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

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

для системы лучше тогда не /usr а /sys

> для системы лучше тогда не /usr а /sys

Это нарушает FHS — раз, и у /sys уже есть своё предназначение — два.

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

Вот это вброс!

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

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

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

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

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

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

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

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

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

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

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

Согласен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну блесни что ли знанием, о зеленый.

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

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

NixOS

о зеленый

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

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

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

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

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

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

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

> NixOS

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

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

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

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

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

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

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

в линуксе.

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

>напиши свою фс чере fuse

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

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

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

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

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

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

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