По-хорошему нужно полностью переделывать структуру ФС.

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

зачем грузить системный каталог в файловом манагере гонома?

«Всё равно»

он, наверное, предлагает initrd размером в 100 мегов =)

yes, yes///

Полностью ЗА. Данная часть стандарта уже давно протухла.

Эта ваша федорка протухла, начинает пованивать, пытаясь занести тухлятину во всю линукс-среду.

Изменения ради изменений. FHS для всех един.

>Not sure, how you managed to do that. In general, having /usr as a separate partition does not really work right now.

Ляха муха! А мужики то и не знали!

//запасаю попкорн в ожидании заявления Линуса о переходе с федорки на что-нить вменяемое.

«не» с глаголами пишется как?

>Q: You are doing it wrong! /bin and /sbin are there to rescue a broken /usr!

A: The most critical filesystem is /boot, because the kernel lives there. So the purpose of having /bin and /sbin for /usr repairing relied on _two_ working filesystems ( / and /boot). If either of them was broken, you were not able to rescue /usr. The role of the rescue system can easily be fulfilled by a rescue initramfs. So having the rescue initramfs in /boot, which contains the fsck utils, is in the same danger of becoming corrupted as the kernel. Now you only have to pull out your rescue CD, if /boot is corrupted and not if / is corrupted.

Вот как раз отдельный /boot зачастую не нужен, ИМХО. Новое железо вроде не имеет проблем с загрузкой из секторов далёких от начала диска, новые загрузчики умеют грузиться с LVM. Отдельный boot пригодится для дуалбута с другим дистрибутивом разве что. Я вот наткнулся один раз на грабли с обновлением при несмонтированном /boot, ССЗБ конечно, но, не вижу причин не держать ядро на / смонтированном только на чтение.

Initramfs вообще костыль, ненужный если в ядре есть поддержка ФС корня. Кстати, если уж бороться за скорость загрузки до такой степени, что переписывать init скрипты на сях, то и initramfs уже не очень тру, наверное. Знающие люди, поправьте.

Q: Then, let’s share /bin /sbin /lib /lib64 and /usr and mount them all from the initramfs!

A: Now, you get a feeling, that moving everything to /usr might make things easier....

mount /bin??! mount /sbin?!! mount /lib!!! Да они там по ходу Моментом упарываются, мозги уже как решето.

не трожь г-но, не будет вони. пусть все остается по старому. к тому же у bin и sbin разное предназначение.

ПРИШЛО ВРЕМЯ ПЕРЕКРОИТЬ FHS
FHS САМ НЕ ПЕРЕКРОИТСЯ
ПЕРЕКРОИ ЕГО, ПЕРКРОИ ЕГО ЕЩЕ РАЗ
ЗАЧЕМ МНЕ НУЖЕН USR, У МЕНЯ НЕТ ВРЕМЕНИ ЧТОБЫ ЕБАТЬСЯ С НИМ
ЛУЧШЕ ЕЩЕ РАЗ ПЕРЕКРОИТЬ FHS
Я ПЕРЕКРАИВАЮ FHS ПО 3 РАЗА В ДЕНЬ
КАЖДАЯ ПЕРЕКРОЙКА ЗАНИМАЕТ ДВАДЦАДЬ МИНУТ
Я ЖИВУ АКТИВНОЙ И ПОЛНОЦЕННОЙ ЖИЗНЬЮ
Я УСПЕШЕН И ПОЭТОМУ ЦЕЛЫЙ ДЕНЬ ПЕРЕЗАГРУЖАЮ СИСТЕМУ
А ПОСЛЕ ЭТОГО ПЕРЕКРАИВАЮ FHS
ТУПЫЕ АДМИНЫ ОДЕРЖИМЫ ЗАТОЧКОЙ СКРИПТОВ
А Я СВОБОДНЫЙ ОТ ЗАДРОТСТВО ЧЕЛОВЕК
СКОЧАТЬ БЕЗПЛАТНО И БЕЗ РЕГИСТРАЦИИ МГНОВЕННАЯ ЗАГРУЗКА
PULS-HHHHHRFSHHHDDIO AVAHI SYSTEMD
ЛУЧШЕ Я ПЕРЕКРОЮ ЕЩЕ РАЗ FHS
А ПОТОМ ЕЩЁ РАЗ, ГИБКОСТЬ НЕ НУЖНА
Я НЕ ПЕРЕКРАИВАЛ FHS НЕДЕЛЮ
ПОЙДУ ПЕРЕКРОЮ
В FHSE ВСЕ СЛОЖНО И НЕПОНЯТНО
SYSTEMD НЕ УМЕЕТ USR. ЭТО ЖЕ ОЧЕВИДНО КАК ЕЕ РЕШИТЬ
ПРИШЛО ВРЕМЯ ПЕРЕКРАИВАТЬ FHS
ККОКОКОКОКОКОКО
ЖМУ/ПИНУС ШВАБОДКА ПИТУХИ
КОКОКОКОКОКОКО

Шамаааан...ну что это за «ненадо»?

Почему?! Имхо, свалка по типу Program Files не нужна. Сейчас разработчик точно знает, что куда помещать при развертывании пакета, из-за этой стандартизации также упрощается код приложения, ответственный за его конфигурацию.

Фактически это приложение объединить каталоги звучит так: «Мы создали „принципиально новую“ (С) систему инициализации и сами же ее не осилили и теперь хотим избавиться от мешающего нам стандарта».

Считаю, нужно объединить /usr/{bin,sbin,games} в /usr/bin, а /bin и /sbin в /bin.

Ибо нет толку от логики «то root-only, а то для всех», хоть это и выглядит всё очень логично.

> Я тебе говорю если эта «базовая система» не имеет выхода «во внешний» мир кроме как через USB и CD-ROM, то нахер она не сдалась.

возможно, что у криворуких идиотов она и не имеет выхода, но у меня ifup ifdown ifconfig route все лежат в /sbin, так что я оттуда могу ходить в интернет

единственная польза от общения с тобой — я заметил, что pppd и pptp таки лежат в /usr/sbin — и это надо поправить

федоровцам сразу сделать необходимо dd if=/dev/null of=/dev/sd* bs=4096 conv=noerror

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

простой пример: в скрипте пишу на dev-машине: #!/usr/bin/ruby, на live-машине вынужден писать #!/usr/local/bin/ruby (ну или наоборот - не суть). Не проще ли писать один раз для всех машин (базовый принцип и идея кросс-платформенности / переносимости?) ? ну а коль таких скриптов, скажем, десяток, сотня или более?

идея изначально, возмножно, была хороша. но вот сейчас мне как-то она не по душе =)

Зачем ломать "стандарт Linux по умолчанию" ?

Пускай любители «клонов» предложат что-либо принципиально новое, а сообщество оценит и выберет лучшее (из двух зол ;-)). НЕ ТРОГАЙТЕ ШЛЯПУ!!!

#!/usr/bin/env python?

И кстати, не BSD ли одна из ваших систем?

нет, к сожалению. за несколько лет руки так и не дошли =) имеете аргументы в пользу / против нее?

что-либо принципиально новое

BolgenOS, коль мне не изменяет память, именно таким и позиционировался =D

>+Надо добавить вариант «вообще всё неправильно, GoboLinux рулит»
Обязательно надо.

Пусть остаётся как было.

А где вариант «выдать разработчикам федоры по лопате» ?

Я за «ничего трогать не надо». В линуксе и так хватает проблем, чтоб ещё заниматься ломкой совместимости.

Правда, вряд ли команда Федоры узнает про этот опрос и тем более обратит на него внимание...

/usr/local это так по бсдшному) и, сдаётся мне, бинарник рубина там не из-за FHS, и даже не пакетным менеджером положен. Прозреваю кривые ручки, но готов поверить и в более серьёзные причины. А сваливание всего и вся в одну папку никак кроссплатформенности не прибавит, особенно в вашем случае.

Проголосовал за объединение bin и sbin, поскольку их разделение было, есть и, к сожалению, буде абсолютным маразмом.
В остальном единственно верное решение реализовано в непопулярном дистрибутиве GoboLinux и в весьма популярной Mac OS X. Сам я компилировал, компилирую и буду компилировать в /opt/<PROG>/<VERSION>.

Принципиальный вопрос заключается в том, что считать «посторонним хламом». Если мы говорим о постороннем в GNU/Linux, то здесь всё, что не из проекта GNU и всё, что не ядро Linux - посторонний хлам. Например, perl - хлам и должен лежать в /opt, а мммм... The GIMP - наше всё, родное, и должно быть в /usr/bin. А вот X-ы - это уже хлам, ату их в /opt!

>+Надо добавить вариант «вообще всё неправильно, GoboLinux рулит»

Надо было добавить, потому что Гобо действительно рулит.

Объединить /usr/local с /usr (точнее, отправить ко всем чертям в поднебесную /usr/local ). /usr/local просто бесит и не нужен.

>> Я тебе говорю если эта «базовая система» не имеет выхода «во внешний» мир кроме как через USB и CD-ROM, то нахер она не сдалась.

возможно, что у криворуких идиотов она и не имеет выхода, но у меня ifup ifdown ifconfig route все лежат в /sbin, так что я оттуда могу ходить в интернет

единственная польза от общения с тобой — я заметил, что pppd и pptp таки лежат в /usr/sbin — и это надо поправить

в конечном итоге — можно вообще все утилиты перенести из /usr/sbin/ в /sbin/

...а теперь хм... чтоже предлагает нам Fedora(?), тыг она так и предлагает(!) — объеденить всё в одну директорию :-)

> Я за «ничего трогать не надо». В линуксе и так хватает проблем, чтоб ещё заниматься ломкой совместимости.

совместимость не пострадает :-)

симвоические ссылкиже будут:

/bin => usr/bin

/sbin => usr/bin

/usr/sbin => bin

Не надо, ибо использую /usr на отдельном разделе...

В Debian такого не будет

Считаю, интересно было бы сделать как в BeOS или GoboLinux, однако корневую иерархию скрывать патчами ядра не надо.
А вообще - всё равно. Совместимость с FHS останется, а дальше пусть каждый дистр делает как ему надо.

пусть объединяют, лишь бы в линуксах ничего не меняли

> когда всё грузится из bash-скрипта...

НЕ нужна утилита mount...
всё это нужно чтобы работало из SystemD...

ФГМ. Полный.

Есть UNIX/BSD/Posix. Там все устоялось десятилетиями.

Если кого не устраивает - ломайте ВСЕ, но не называйте результат UNIX/BSD/Posix-совместимым.

+100 Федоровцы упоролись.

Ничего трогать не надо

«Надо» это не глагол. Но тоже раздельно, ага :)

Если так уж руки чешутся, пусть объединят /bin и /sbin.

А совать /usr в корень — это глупость, за которую надо отрывать руки и вправлять мозги. Сейчас есть возможность поставить /usr в отдельный раздел на LVM с правами read-only, причём сделать это без возни с initrd. Если реализуют предложенное, эта возможность исчезнет. Казнил бы!

>какая ещё дыра? :-) ...suid-бинарники искореняют из дистрибутипов

Боги... Доступ к ним и так у всех есть. Проверь. Дело не доступе. Дело в разумном разделении.

Ну в Линуксе только переменная path осталась для разделения «прав». В других Юникс, особо старых, права там разные..

Так что и в доступе тоже... Да сейчас многие дают доступ к sbin, это потому что они используют sudo и там дают права админам... Но можно без sudo дать права запускать программы с sbin группе wheel с правами рута... И когда все они лежат в ОТДЕЛЬНОМ каталоге права човнать и чмодать удобнее...

....а если вы НЕ дадите доступ к какой-то из /sbin/* программ юзеру (например так часто делают на www-хостингах, плохая идея конешно), то с чего вдруг администратор думает что юзер себе в /home/the-usr/.local/sbin/ не накопирует нужного барахла своими силами?

/home, /tmp, /var (с /var/tmp) - у всех нормальных людей отдельные разделы с опцией noexec.

Всё где есть исполняемые файлы монтируется ro Всё что монтируется rw также монтируется с опцией noexec Эти правила написаны кровью! Также эти два правила оказали влияние на традиционную структуру каталогов UNIX и традиционную практику разбиение разделов при установки UNIX.

>Принципиальный вопрос заключается в том, что считать «посторонним хламом». Если мы говорим о постороннем в GNU/Linux, то здесь всё, что не из проекта GNU и всё, что не ядро Linux - посторонний хлам. Например, perl - хлам и должен лежать в /opt, а мммм... The GIMP - наше всё, родное, и должно быть в /usr/bin. А вот X-ы - это уже хлам, ату их в /opt!

4.2 У меня Джента:

ls /opt/ Adobe icedtea6-bin-1.10.4 icedtea6-web-bin noc sun-jre-bin-1.6.0.29

Весь перл и Х в /usr!!! даже не в /usr/local...

>Считаю, нужно объединить /usr/{bin,sbin,games} в /usr/bin, а /bin и /sbin в /bin.

Ибо нет толку от логики «то root-only, а то для всех», хоть это и выглядит всё очень логично.

Удобно разделять доступ! И глазами контролировать права в sbin

> /home, /tmp, /var (с /var/tmp) - у всех нормальных людей отдельные разделы с опцией noexec.

недавно устанавливал Squeeze, выбрал tmp отдельным разделом с noexec, в итоге ошибка при установке пакетов; убрал noexec, все поставилось.

Они наверно ВРЕМЕННЫЕ скрипты туда положили.. Это не есть гуд! После установки верните noexec!