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

И всё же не совсем видна необходимость переноса /var/run в /run, во всех стартовых сценариях прописана зависимость предварительного запуска localmount перед продолжением загрузки системы, т.е. пока не будут смонтированы все файловые системы, указанные в fstab и /var, если он вынесен, не будут запускаться прочие стартовые сценарии. К тому же после переноса run нельзя будет монтировать корень в ro. Так что особого смысла в таком переносе нет. К тому же зачем смешивать логически выверенную структуру разделов, то что должно быть доступно для изменения должно находиться в /var.

> Ты хотя бы в курсе, что Gobo FHS-совместима?

Про это просто нельзя не знать: http://wiki.gobolinux.org/index.php?title=The_GoboLinux_Way

«There are symbolic links relating most of the usual UNIX directories to the GoboLinux tree. Therefore, you will find directories such as /etc, /var/log and /usr/bin in the expected places.»

Но «совместима» именно в режиме «поддерживать старое гумно». Основной режим - это их новая иерархия (для чего она и была придумана - ЗАМЕНИТЬ существующую помойку).

> Вы готовы логически доказать:

Для тюленей вроде тебя есть официальная страница сайта: http://wiki.gobolinux.org/index.php?title=Main_Page - читай, спорь, доказывай. Я всё это прочёл и счёл абсолютно верным (хотя бы идейно). Развивать там ещё есть что, но хотя бы логически обоснованная база есть.

> Основной режим - это их новая иерархия (для чего она и была придумана - ЗАМЕНИТЬ существующую помойку).

Датычо. А ничего, что она почти полностью дублирует каталоги FHS под другими названиями?

> Gobo это такой mac os с линукячьим лицом? :) Оно вообще живое?

Нет, макосью там даже не пахнет.
К сожалению, проект стухает - Майкл там чота планировал-планировал, да не выпланировал (поддержка гетерогенных пакетов). Ещё убивает то, что все скрипты написаны на баше - немного найдётся спецов, досконально знающих интерпретатор, чтобы импрувить. Перл был бы куда разумнее.
Энивэй, сама система концептуально очень интересна и более того - имеет вполне работоспособное воплощение. Жаль, что её закидывают калом раньше, чем удосужились поставить (хотя бы «чисто приколоться»).
Я сам за ней работал года два - и пакеты сам делал, и ставил, и «хирургически обновлял» - при том, что самим Линуксом занимаюсь чисто «для себя» - проблем не испытывал. Вот куда бы направить усилия всех этих штопаных «стандартизаторов»!

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

Только в вашем больном воображении. FHS фактически тусует с места на место старую помойку, Gobo же предлагает ЕДИНУЮ иерархию для всего:

:-- etc -> System/Settings
:-- dev -> System/Kernel/Devices
:-- sys -> System/Kernel/Objects
:-- proc -> System/Kernel/Status
:-- var -> System/Variable
:-- tmp -> System/Variable/tmp
:-- sbin -> System/Links/Executables
:-- bin -> System/Links/Executables
:-- lib -> System/Links/Libraries

Как НЕТРУДНО ЗАМЕТИТЬ, куча ересищщи, придуманной красноглазиками, схлопывается в логичные каталоги, причём программы (В ОТЛИЧИИ ОТ FHS) лежат в ОДНОМ месте - /Programs. Вы наверное слишком поверхностно ознакомились с темой, раз делаете такие ламерские заявления. Я крайне вам рекомендую прочитать ещё раз, насколько иерархия Gobo радикально отличается от FHS и всего Линукс-мира.

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

Благодарю за разъяснения.

На это никто не пойдет.

LD_LIBRARY_PATH какой-нибудь тогда на старую версию библиотеки.

> Gobo же предлагает ЕДИНУЮ иерархию для всего:

Что и требовалось доказать. Те же каталоги, вид сбоку.

насколько иерархия Gobo радикально отличается от FHS и всего Линукс-мира.

Лисапед не нужен, т.к. ни на йоту не улучшает управление пакетами. Идея использовать структуру ФС как базу данных пакетов еще имела бы смысл (например можно легко из говна поднять развалившуюся систему, даже если их питономенеджер пакетов сломается), если бы они не Страдали/Болезнью/Придумывать/Идиотские/Названия/Каталогов — а так получилось, что достоинство скомпенсированно недостатком.

Говно, а не иерархия. Идеи у них хорошие, но воплощение - говно

/usr/games да и games вообще не нужно на Linux.

точно ибо '/' и есть '/game/linux/'

>И всё же не совсем видна необходимость переноса /var/run в /run, во всех стартовых сценариях прописана зависимость предварительного запуска localmount перед продолжением загрузки системы, т.е. пока не будут смонтированы все файловые системы, указанные в fstab и /var, если он вынесен, не будут запускаться прочие стартовые сценарии.

а если он вообще не смонтировался?

К тому же после переноса run нельзя будет монтировать корень в ro.

Понятно. Обкурился ты в хламину...

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

Ну так для этого чрут и хорош. Если архитектура и ядро совместимы.

А так, лучше в виртуалочке тестить.

вот это врядли. сделав снепшот ты морозишь текущее состояние. А тут нужно иметь два параллельно изменяемых образа.

Сам ты обкурился в хламину. У меня корень, /usr, /opt в ro, только home, var, tmp доступны на запись.

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

/srv - нах
по-человечски - /home на отдельную партицию и /home/http /home/ftp и т.д.

Сам ты обкурился в хламину. У меня корень в ro,

1) конфиги ты не меняешь, молодец. А /etc/mtab куда дел?

2) каким образом +1 точка монтирования /run может изменить положение дел, раз уже есть три точки монтирования home, var, tmp доступны на запись?

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

«нужно разбираться» == «пытаться работать в наполовину действующей системе»

# ln -s /proc/mounts /etc/mtab

Конфиги меняю, но редко, раз в месяц, а то и реже.

Т.е. вы теперь мне предлагаете еще и для /run отдельный раздел сделать, зачем если здесь будут лежать переменные данные, а именно информация о pid запущенных сервисов, место которым в /var/run, можно конечно ссылку сделать, но обратную, /run -> /var/run, но это изврат, ибо не нужно портить то, что уже сейчас логично работает.

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

man tmpfs, блджад!

Зачем ? И желательно всё же представиться.

> Т.е. вы теперь мне предлагаете еще и для /run отдельный раздел сделать

А у тебя что, для /dev, /proc и /sys выделены отдельный разделы? Ты точно укурен в хлам.

> Зачем ? И желательно всё же представиться.

А зачем у тебя /dev в tmpfs?

Отличные изменения.

И что из этого что dev в tmpfs, это псевдо фс, которую монтирует ядро на точку монтирвоания /dev, она создаётся в пространстве памяти ядра и должна быть доступна на запись, для создания новых блочных и символьгых устройств в случае изменения аппаратной конфигурации при подключении нового оборудования, usb накопителя например.

Где из моих сообщений видно, что я вынес /dev /proc /sys на отдельные разделы, да и зачем, т.к. это всё псевдо файловые системы, которые формирует ядро в своем пространстве памяти и при подключении корня монтирует их на точки монтирования в корневой системе. Их вынести нельзя.

Что то у вас много сообщений про укурку, бросайте это дело, к добру не приведёт.

Т.е. вы теперь мне предлагаете еще и для /run отдельный раздел сделать,

а он и есть отдельный раздел в tmpfs. Там сотня файлов по 5 байт абсолютно неактуальная после выключения.

зачем если здесь будут лежать переменные данные, а именно информация о pid запущенных сервисов,

/proc тоже?

место которым в /var/run,

уже тыщщу раз объяснили, что /var может не смонтироваться. Поэтому и хотят убрать зависимость от всего необязательного.

>т.к. это всё псевдо файловые системы, которые формирует ядро

понятно. иди и читай.

Ну почитайте мои ответы хотя бы на пост вышему вашему коллеге: http://www.linux.org.ru/news/linux-general/6567793/page6?lastmod=1312462173262#comment-6574035 (комментарий)

Про /proc /sys /dev я ответил в этом сообщении, еще раз переписывать не буду.

Насчёт /var, если вы не поняли из моего предыдущего вам ответа, если /var не смонтируется, то даже если сервисы запустятся и сохранят pid запущенных ими процессов в /run/<name_servis>/pid-***, то они будут в большинстве своём не работоспособны, т.к. их рабочие данные лежат в /var и после его подмонтирования их всё равно придётся перезапускать.

Смысл от того что у вас будут сохранены их pid`ы не большой. И вообще этот спор не особо важен, вы как я смотрю не хотите осмысливать мои аргументы и стоит только на своём мнении.

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
(rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
udev on /dev type tmpfs (rw,nosuid,relatime,size=10240k,mode=755)

Что вам понятно, где по вашему мнению физически находятся данные этих фс ? Первые две создает само ядро, во время своей работы и затем они биндятся. Последняя создается в памяти и тоже биндится на /dev.

Читайте книжки. Учите английский.

Все файловые системы монтируются в свои точки монтирования. Нет разницы, procfs это или devfs или usbfs или tmpfs. Нет точки монтирования - нет смонтированной системы. Ядру пофиг, куда монтировать proc - можно было бы смонтировать ее в /var/proc

Насчёт /var, если вы не поняли из моего предыдущего вам ответа, если /var не смонтируется, то даже если сервисы запустятся и сохранят pid запущенных ими процессов в /run/<name_servis>/pid-***, то они будут в большинстве своём не работоспособны,

Сервисы или стартуют или нет. В любом случае информация об их запуске и статусе будет верной. Для этого и держат в том числе каталог run.

>Что вам понятно, где по вашему мнению физически находятся данные этих фс ? Первые две создает само ядро, во время своей работы и затем они биндятся. Последняя создается в памяти и тоже биндится на /dev.

а ядро у астрале, а не в памяти? Все это файловые системы, все это модули ядра.

У вас какая то странная логика, где вы прочитали что я отрицаю, что proc, devfs и sysfs - монтируются в точки монтирования и что если нет точки монтирования для этих фс то они будут смонтированы., вы высасываете нелепицу из пальца.

Если вы явно укажете в fstab монтироваь, к примеру proсfs в /var/proc, то она туда смонтируется, но зачем?

Мне что надо писать всё досканально, что бы вам стало ясно или вы просто ТРОЛИТЕ, в таком случае вам должно быть СТЫДНО.

Троллите тут только вы. Рассужденрями, что /run мешает вам корень в ro смонтировать.

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

Если не чего сказать разумного, то стоит промолчать.

>Если вы явно укажете в fstab монтироваь, к примеру proсfs в /var/proc, то она туда смонтируется, но зачем?

а зачем /run монтировать в /var/run? Об этом и речь, что незачем...

Раньше это было затем, что не было никаких tmpfs (и procfs кстати тоже) и никому не было интересно делать еще один каталог в корне.

а теперь давно уже пора вынести, вот и вынесли.

Давно пора /var разгрузить. Хватит в горах ненужностей копаться. Ну вот игры моя не понимать. У нас же есть /opt для стороннего софта. Почему бы туда и /games не запилить... Нахрена /usr/bin засорять-то О.о X11R6 выпилить. +1. /lib32 | /lib64 true. Что касается хранения конфигурций DE\WM. Opendesktop намекает: .config/kde4

Тогда что мешает?

>Ну вот игры моя не понимать. У нас же есть /opt для стороннего софта

а кто сказал, что игры - сторонний софт? они такая же часть дистра. в пакетах.

в /opt стваится то, что ставится руками в виде /opt/программа

Интересно. А я вот недавно поставил крутую игру fortune в федоре 15 (LORquotes там посмеятся и всё такое) и значит засую её запуск в ~/.bashrc, а нету в games. Я даже удивился. Смотрю, а она в bin лежит себе. Правильно наверное. Это раньше народ не знал как игры найти - увидев директорию games же конечно сразу радовался и играл. Теперь это ни к чему уже это, тем более игр нет всё равно.

Извините, *посмеяться конечно же.

Как в анекдоте про коммунизм.

У кого-то есть в линуксе игры, а у кого-то нет...

в /opt стваится то, что ставится руками в виде /opt/программа

Это понятно. Другое дело, что лично я не понимаю целесообразости не системных программ-приложений в данной директории. Имхо - они в /usr/bin без надобности. Не могу я предствать себе w, wich, env, file, top в одной мусорке с каким-нить teeworld или еще чем. Уж простите. ps: у меня неправильный дистр. У меня нет игр ):

> И всё же не совсем видна необходимость переноса /var/run в /run, во всех стартовых сценариях прописана зависимость предварительного запуска localmount перед продолжением загрузки системы

Проблема в том, что, кроме инитскриптов с номерами и зависимостями, существуют другие способы запуска программ. В частности, правила udev тоже умеют запускать init-скрипты, и в этом случае зависимости (в том числе от localmount) не учитываются.

К тому же после переноса run нельзя будет монтировать корень в ro.

/run обязан быть смонтирован как tmpfs. В этом и состоит вся задумка. /var - для данных, которые должны сохраниться после перезагрузки, /run - для данных, которые должны исчезнуть после перезагрузки.

Вдогонку: корень смонтировать в ro как раз можно, именно из-за того, что /run - это tmpfs, которая монтируется в первую очередь после /proc.

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

а там и нет системных. или все системные. Там бинарники программ, а не отношение к ним.

Имхо - они в /usr/bin без надобности. Не могу я предствать себе w, wich, env, file, top в одной мусорке с каким-нить teeworld или еще чем. Уж простите.

ну и зря. Для кого-то fortune, это серьезно, повод задуматься.

ps: у меня неправильный дистр. У меня нет игр ):

тем более, чего тогда встревать?

> вот это врядли. сделав снепшот ты морозишь текущее состояние. А тут нужно иметь два параллельно изменяемых образа.

дык вроде какие то ФС обладают *изменяемыми* снапшотами - по сути отдельными ветками изменения данных.