Деды воевали^W FHS писали! Да как вы смеете покушаться на святое!

> Более того, размещение /usr на отдельной файловой системе вызывает проблемы при загрузе посредством systemd;

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

канеш, как еще забивание раздела под / сделать почти нерешаемой проблемой

Я не люблю тыкать по ссылкам.

Тогда что вы делаете в интернете?

Зачем портить, удобно же было, можно было / на один диск, а /usr - на другой? Удобно, если, например, два харда - один маленький (гигов 10), а другой побольше (гигов 50).

>Или так: /etc, /setc (только для админов — зачем неискушённому пользователю все настройки показывать?)
Неискушённый пользователшь итак в /etc/ лазить не должен. А вот в автодополнении команд обычному пользьвателю всякие *conf* не нужны.

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

на главной подумал «опять Леннарт фигнёй страдает». Заглянул — надо же, так и есть!

http://www.linux-community.de/var/ezwebin_site/storage/images/medien/images/l...

Вот оно ... лицо поколения пепси :)

Поддерживаю! Ну нужна эта куча разных каталогов, выполняющих одну и ту же функцию.

> Поддерживаю! Ну нужна эта куча разных каталогов, выполняющих одну и ту же функцию.

Дык функции-то разные.

>Ну а бородатые старперы,

Тупая школота, слушающая музычку на кампутерах и лазящая в интернетах.

Еретики!!!

> Правильно. Надо ещё и другие каталоги разнести. Все настройки в /etc — непорядок! Надо разнести их по /etc, /usr/etc, /usr/share/etc, /var/local/share/data/etc, /usr/local/data/doc/lib/etc/. Или так: /etc, /setc (только для админов — зачем неискушённому пользователю все настройки показывать?), /usr/etc, /usr/setc, /lib/etc и т. д..

Не показывайте себя необразованным недо-админом. В /etc пользователь и так не должен лазить.

А вот /usr/etc видел, не помню уже какая софтина норовила туда конфиги свои забросить при make install :)

Во фряхе, если мне не изменяет память, /usr/local/etc вполне имеет место быть.

Когда то очень давно, когда я начинал работать с UNIX, в студенческие времена, /bin и /lib без смонтированного /usr действительно представлял собой минимальную реально работающую систему. Пригодную для запуска например fsck. А сейчас это действительно не работает и дело не в багах, а в том что современные приложения сконфикурированы с обязательным присутствием /usr. И старая двухуровневая конфикурация действительно давно изжила себя и никто из разработчиков не подразумевает возможности работы чего бы то ни было в варианте без /usr. То, что раньше делалось из минимальной системы без смонтированной /usr, уже давно делается из initrd или при ручном восстановлении из livecd. Так что я считаю эту идею весьма здравой.

>Так что в яблочной компании совсем не глупые люди, раз выдали публике /Applications

в яблочной компании как раз считают что место пользователя в /Home/%UserName%

>А вот /usr/etc видел, не помню уже какая софтина норовила туда конфиги свои забросить при make install :)

тут ты как недоадмин и спалился

>в яблочной компании как раз считают что место пользователя в /Home/%UserName%

/Users/

Для Ъ, ругающих systemd, цитата по ссылке:

1. It isn't systemd's fault. systemd works fine with /usr on a separate file system that is not pre-mounted at boot.

2. systemd is merely the messenger. Don't shoot the messenger.

3. There's no news in all of this. The message you saw is just a statement of fact, describing the status quo. Things have been this way since a while.

Проблема в том, что многие программы лезут в /usr до его монтирования. Неполный список программ:

udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, the locale logic of most programs and a lot of other stuff.

> Во фряхе, если мне не изменяет память, /usr/local/etc вполне имеет место быть.

Во, точно! Именно /usr/local/etc это и было. Только на Linux, при make install.

> тут ты как недоадмин и спалился

А поподробнее вашу логику можно? Или установка дома на тестовой системе программы через make install (а точнее - checkinstall) - это что-то плохое?

ConsoleKit

console-kit-daemon.pid

Вот поэтому у меня жуткая ненависть к всем этим инноваторам.

Работает - НЕ ТРОЖЬ!!

А давайте вообще сделаем один огромный бинарник?

Проблема в том, что многие программы лезут в /usr до его монтирования.

Так почему же они без systemd так себя не ведут? А то он глюки своего пульсаудио тоже всю дорогу на альсу валил.

В Солярке /bin -> /usr/bin

unsigned> снятие снапшотов станет действительно атомарной операцией. В настоящее время btrfs требует 5 снимков - /lib, /lib64, /bin, /sbin и /usr вместо одного, что неудобно и может приводить к состояниям гонки;

ИМХО абсурд - вместо того, чтобы не допускать гонку - предлагают поменять организацию системных каталогов ОС.

>ну на кой, скажите мне сейчас /usr на отдельном разделе в linux нужен?

отдельный / нужен, потому что не все фс после сбоя в монтируются в rw режиме, а загрузится в ro иногда не в состоянии, неудобно делать их проверку, есть каталог /tmp, который доступен для записи для всех, он может переполнится, что приведет к разным глюкам (то что /tmp - tmpfs не аргумент, она может не успеть подмонтироваться или не всегда так можно сделать), у разных fs в linux разные возможности и стабильность, в результате, часто для / выбирают другие fs или опции монтирования.

> udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, the locale logic of most programs and a lot of other stuff.

А... ну-ну. Почти всё из этого то, что появилось в Linux в последние 5-10 лет. Когда все начали массово класть болт на unix-way.

P.S. И нафига мне запуск CUPS, ALSA и тем более - PulseAudio до монтирования /usr? Пусть потом запускаются. А остальной софт пофиксить надо. А не ломать нафиг всю систему.

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

bigbin --ls

Так почему же они без systemd так себя не ведут?

Вроде systemd позже монтирует /usr. А почему это нельзя исправить - я не понял.

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

ip ro
bash: ip: команда не найдена
/sbin/ip ro
default via 192.168.1.254 dev eth0 metric 10
169.254.0.0/16 dev eth0 scope link metric 10
169.254.0.0/16 dev eth0 scope link metric 1002
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.17 metric 10

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

Почему не ведут? Ведут. Только без systemd на момент их запуска /usr уже смонтирован, вот и работает всё.

А почему это нельзя исправить - я не понял.

Потому что проще же поломать иерархию ФС, и тогда об этой проблеме все забудут.

Зачем ключи? Лучше симлинки и проверка argv[0] при запуске.

Дайте лопату. Пора откапывать BSD.

man NTFS Junction Point

>bigbin ./rm /bin/bidbin

Как то так :-)

Ненависть.

Трындец.

разделение на /bin и /sbin приводит к усложнению работы разработчиков, которые зачастую ошибаются с выбором каталога, либо бездумно помещают файлы в /usr/bin;

Написать уже нормальный гайдлайн.

первоначальное назначение каталога /sbin (размещение статически собранных файлов, на что указывает буква «s») давно неактуально;

Да ну.

разделение на /bin и /sbin не имеет отношения к безопасности (это был бы глупый принцип «security by obscurity»);

Да. Для безопасности есть права. Зачем делаете o+x reboot если это всё равно не работает для юзеров?

разделение на /bin и /sbin имеет значение только для переменной $PATH, однако усложнять доступ пользователей к некоторым инструментам - плохая затея; к тому же для этого есть более подходящие каталоги;

Разделение имеет значение только для программы mount.

разделение на /bin и /sbin в любом случае бессмысленно уже пару версий Fedora, поскольку оба каталога включены в переменную $PATH для всех пользователей;

см выше. И сами же сказали, что секурность непричём.

разделение приводит к усложнению, а мы должны стремиться к упрощению;

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

различные дистрибутивы размещают некоторые бинарные файлы в различных каталогах, что приводит к проблемам с переносимостью скриптов;

Так $PATH на что?

разделение на /bin и /usr/bin в основном было сделано для этапа ранней загрузки системы - минимальный набор загрузочных файлов находится в /. Но это давно не работает, и соответствующая опция убрана из инсталлятора anaconda. Более того, размещение /usr на отдельной файловой системе вызывает проблемы при загрузе посредством systemd;

Почините баги в systemd. Выкиньте анаконду и напишите нормальный инсталлятор.

разделение на минимальную систему в / и полную в /usr также стало бессмысленно благодаря initrd, а содержание двух уровней «минимальной загрузочной системы» - дурацкая затея;

initrd - костыль, вот его-то надо выкинуть. Сменил видюху не сделав mkinitrd - система не загрузилась, очень удобно, блин.

существенно упростится установка «read-only» системы: так, libc и другие системные библиотеки будут доступны только на чтение, а /etc - на чтение и запись;

Лучше бы вы сделали так, чтобы /etc можно было в ридонли смонтировать.

снятие снапшотов станет действительно атомарной операцией. В настоящее время btrfs требует 5 снимков - /lib, /lib64, /bin, /sbin и /usr вместо одного, что неудобно и может приводить к состояниям гонки;

btrfs не готов, чините btrfs. Кстати, на LVM таких проблем нет, особенно если /etc на отдельном разделе. Разделять lib для разных архитекртур всё равно придётся. Предвижу появление /lib.arm и /lib.opencl на мультипроцессорных машинах в будущем.

существенно упростятся сетевая и контейнерная установки;

«существенно»? С чего-бы?

сборочные скрипты упростятся: в частности, autoconf не знает о разделении на / и /usr, и для правильной работы с ними приходится прилагать специальные усилия;

Вы ещё и свой несовместимый autoconf хотите, наркоманы?

эксперименты уже показали жизнеспособность предложенной схемы и отсутствие серьезных проблем;

Ваши эксперименты в соответствии к критерием Попплера отправляются в /dev/null.

есть разработчик (Harald Hoyer), готовый выполнить необходимую работу.

А что, Леннарт занят? Наконец-то фиксит сегфолты в пульсаудио?

Ведут. Только без systemd на момент их запуска /usr уже смонтирован

/0
Проги лезут в /usr до того, как он монтируется, но к этому моменту он уже смонтирован?

s/bidbin/bigbin/g

> То, что раньше делалось из минимальной системы без смонтированной /usr, уже давно делается из initrd

А как быть тем, кто собирает монолит?

федорино горе!

>> То, что раньше делалось из минимальной системы без смонтированной /usr, уже давно делается из initrd

А как быть тем, кто собирает монолит?

Монолит как бы абсолютно параллелен initrd...

> Монолит как бы абсолютно параллелен initrd...

Да ладно! У меня в слаке initrd делает одну-единственную полезную вещь: подгружает reiserfs.ko. Всё. Так что не абсолютно.

> /0

Проги лезут в /usr до того, как он монтируется, но к этому моменту он уже смонтирован?

Нет конечно. Просто без systemd /usr монтируется до запуска этих прог стартовыми скриптами, которые либо в initrd, либо /etc/init.d.

А systemd - событийная штука, которая монтирует /usr когда звёзды на небе станут в нужное положение (читай: кто-то попросит его смонтировать).

Только вот непонятно - почему проще поломать иерархию ФС, чем добавить в зависимости этих программ смонтированный /usr?

>А поподробнее вашу логику можно? Или установка дома на тестовой системе программы через make install (а точнее - checkinstall) - это что-то плохое?

Логика простая. Ты ставил в жизни только одну программу через make install, которая кладёт что-то в $(PREFIX)/etc и не прочитал внимательно configure --help

На самом деле все почти программы, которые ставятся через make install и хотят etc, установят что-то в /usr/local/etc/

> Неполный список программ: ...PulseAudio, NetworkManager, ModemManager, udisks...

На 50% состоит из поделок этого самого Пёттеринга. А что там делают gnome-color-manager, ALSA, CUPS вообще не понятно. Видать приплёл для пущей важности.

О.. теперь я знаю чем bin от sbin отличается.. Раньше думал, что это security bin, в котором лежит то, что не нужно не руту.

Только вот непонятно - почему проще поломать иерархию ФС, чем добавить в зависимости этих программ смонтированный /usr?

Вот и мне непонятно...