Разработчики Fedora обсуждают объединение каталогов для исполняемых файлов

разделение на минимальную систему в / и полную в /usr также стало бессмысленно благодаря initrd

А если я не хочу initrd? А может в моём монолитном ядре вообще модули не подгружаются, всё что мне надо вкомпилил, а что не надо выкинул... Грузится ядро и сразу система с минимального /

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

конечно диски у нас никогда не сыпятся, их чекать не надо.. Но в мире осталось пару упрямых программистов которые НЕ ХОТЯТ писать нормально проги, по этому мне для загрузки кед в hardened системе приходится сначала загрузится до минимальной системы, примонтировать /usr для записи, выполнить:

paxctl -m /usr/bin/kwin
paxctl -m /usr/bin/kdeinit4

перемонтировать /usr только для чтения и только теперь продолжить загрузку и загрузить кеды...

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

Хорошая идея с установкой «read-only» системы, одобряю! Признаюсь у меня проблем не возникает и что там упростить ещё кому надо я не знаю... Да, /etc я держу только для чтения, там тоже есть исполняемые файлы, как и весь /. Раз в пару месяцев при обновлении и изменении конфигов, паролей перевожу разделы в режим для записи, а потом обратно только для чтения.

ЗЫ: Передавайте пламенный привет https://fedoraproject.org/wiki/User:Harald и разрабам systemd чтобы профиксили http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken, также все другие баги в проэктировании и разработки и не делали революций!

Хотя мне абсолютно всё равно как работает федорка, это сугубо интимная проблема её пользователей, пусть её и решают КАК ИМЕННО ИМ удобно! Могут вообще от каталогов и разбиения дисков отказаться, все файлы прямо в корне держать... :)

> Некоторые программы, как ifconfig нужны обычному пользователю

У кого убунту головного мозга должны тыкать в картиночку с всплавающей подсказкой нетворкманагер. Нафиг вы все в консоль то лезет с такими запросами?

> Я себе не представляю работу без этих программ. Это базовые программы, которые требуются для работы других программ.

А ls, cat и grep? %)

Да, безусловно, все это - нужные программы. Но зачем они руту? Можно узнать пример ситуации где они ему нужны? Руту надо устанавливать и удалять пакеты, да, еще ему надо менять их настройки. Это и есть задача рута - настроить систему для работы. Работа в системе выполняется от пользователя. И все эти ls/cat/grep запускаются от пользователя. Руту-то они зачем? ;)

> все эти ls/cat/grep запускаются от пользователя. Руту-то они зачем? ;)

Ну, Капитан намекает, что grep используется для поиска строк в файлах, ls - для просмотра каталогов, а cat - когда нужно по-быстрому что-то просмотреть или скопировать. Я правильно понимаю - ты хочешь сказать, что руту не нужно ничего искать, не нужно просматривать содержимое каталогов и файлов?

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

Называйте примеры, когда это нужно именно руту, обсудим. Много ли примеров наберется?

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

Называйте примеры, когда это нужно именно руту, обсудим.

Для начала я бы хотел, чтобы ты четко высказал свою точку зрения. Если я ее правильно понял, она просто не заслуживает обсуждения.

> Для начала я бы хотел, чтобы ты четко высказал свою точку зрения.

Точки зрения нет, есть идея для обсуждения. Я предлагаю обсудить идею: наличие каталога /sbin/ в PATH нужно юзеру примерно на столько же, насколько наличие каталога /bin/ в PATH нужно руту. Вот я и прошу тех, кто считает, что /bin/ в PATH-е нужен руту, привести примеры случаев, в которых он ему нужен.

Шелл админу нужен? А ведь он в /bin...

Лазить по директориям при настройке админу надо или лучше наизусть помнить пути ко всем 100500 конфигам? А ведь тот же ls в /bin лежит...

Искать нужные конфиги админу надо или таки помнить все наизусть? А ведь grep в /bin...

Делать временные бэкапы редактируемых конфигов админу надо? А ведь cp в /bin...

Чистить хлам вроде тех же бэкапов, когда все настроено и работает, админу надо? А ведь rm в /bin...

Управлять правами и пр. админу надо? А ведь chmod&co в /bin...

Конечно, часть этого добра может быть встроена в шелл (который, блджад, в /bin), но далеко не все.

> Шелл админу нужен? А ведь он в /bin...

Во-первых, не любой шелл в /bin (привет, busybox), во-вторых, он, конечно, нужен, только запустится он сам, а запускать его явно админу не надо.

Лазить по директориям при настройке админу надо или лучше наизусть помнить пути ко всем 100500 конфигам? А ведь тот же ls в /bin лежит...

Есть ли случаи, когда админу пришлось бы использовать ls, разве автодополнения не достаточно?:
vi /e<tab>squ<tab><tab><tab>sq<tab><enter>

Искать нужные конфиги админу надо или таки помнить все наизусть? А ведь grep в /bin...

Интересно, как же греп поможет найти конфиг? Можно примерчик из жизни?

Делать временные бэкапы редактируемых конфигов админу надо? А ведь cp в /bin...

А зачем? Опять-таки, можно пример из жизни, когда это было бы нужно? Если будет пример того, где это было нужно, то я на этом примере смогу показать, почему для этого не нужны были права рута. :)

Чистить хлам вроде тех же бэкапов, когда все настроено и работает, админу надо? А ведь rm в /bin...

Бакапы хранятся у отдельного _пользователя_ (и на другой машине), руту нет нужды в них лазить.

Управлять правами и пр. админу надо? А ведь chmod&co в /bin...

Нет, не надо. Пакетный менеджер сделает это за него.

Где конкретные примеры, когда именно руту нужно выполнять программы из /bin-а (не считая rpm и vi, которые уже были названы)? Пример - это описание задачи и последовательности действий для ее решения. Найдутся такие?

Виноват, исправлюсь. Перепутал.

Глобально переделать все это пробовали (см. GoboLinux) — не взлетело.

Чушь какая... наверное, у онанизмуса своё видение «успеха»? Gobo победил уже тем, что ВСЯ СИСТЕМА органично вписалась в новую иерархию, значительно упростив работу. Просто ржач пробирает на обсуждение тухлых /bin /sbin /usr/share/bin /usr/local/bin и прочей вермишели. Некоторым надо просто себе признаться: «я потратил кучу времени на заплесневелые принципы 70-ых и очень к ним привык. Мой мозг закостенел и мне тупо ссыкотно что-то менять в системе». А автор Гобо имеет яйца, поэтому взял и сделал.

>> Глобально переделать все это пробовали (см. GoboLinux) — не взлетело.

Чушь какая... наверное, у онанизмуса своё видение «успеха»?

Успех - это не то, что Мумба считает успехом.

А автор Гобо имеет яйца

...а вот с мозгами у него не очень.

А как тогда смонтировать /usr, если он на отдельном разделе?

Плюсую! да че уж там, нужно просто сделать папку /Program Files

Хм. И как теперь делить системный уровень с пользовательским? Теперь ifconfig tcpdump и firefox будут лежать рядом?

Найдутся такие?

grep,sed,awk,ls,echo,cat,tail,head - без всего этого, молодой человек, у вас большая часть шелл-скриптов не выполнится, и то, что coreutils - является неотъемлемой частью инициализации этих вашил линуксов, какбы намекает. Что рут без /bin это как президент ООН на северном полюсе, прав дох..я, а ими и костёр не разожжёшь.

>Вот, кстати, никогда не понимал, зачем такие симлинки.

Потому что версий awk в системе может быть несколько, так же как и bash, а gawk находится в /bin, потому что им пользуются скрипты загрузки.

На самом же деле - не поэтому.

AWK - это интерпретатор языка программирования, следовательно его частенько прописывают в начале скрипта в первой строчке:

#!/usr/bin/awk -f

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

Так вот, программист, пишуший скрипт на AWK не обязан быть в курсе, где на вашей конкретной системе в конкретный момент времени живёт бинарник AWK. Вчера в /usr/bin/awk, сегодня в /bin/awk, завтра - ХЕЗ.

Вот поэтому для всех видов интерпретаторов, позволяющих запускать скрипты как исполняемые файлы, будет стоять такой выбор: переписать КАЖДЫЙ скрипт нахер (да, почитатели Портеринга, да, КАЖДЫЙ во вселенной скрипт переписать, либо объявить вне закона, устаревшим, застрявшим в 80-х и т.д.), либо ВЕЧНО сохранять хотя бы ссылки во всех традиционных местах, где когда-либо размещались интерпретаторы в каких-либо системах. Удалить /usr/bin не выйдет, пока ещё есть скрипты на петоне, запускающиеся как #!/usr/bin/python

Можно ещё вдолбить программистам, что лучше писать:

#!/usr/bin/env awk -f

чтобы env сам нашёл в PATH бинарник awk, где бы он ни лежал. Но это аналогично по сложности переписыванию ВСЕХ скриптов во вселенной. Кстати, Потеррасты здесь предложат написать систему с модулем для ядра, которая бы автоматически исправляла первую строчку файла при его запуске. Ловите идею, C*KИ!!!

А вы не знали. А это ещё не всё, что вы не знали, ей богу.

Зачем нужен FHS?

Представьте себе, что у вас не домашний люнекс, а 100500 машин в громадном таком университете, например, ну или не менее 10000 штук в нескольких разделённых офисах. А Вы - администратор всего этого счастья.

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

Допустим, у Вас только Linux. Допустим, что машины более-менее однотипные, но тем не менее немного различающиеся мелочами в железках. Не везде есть принтер, например. Или card-reader. Или ещё хз чего.

Однако, как вы себе представляете создание 10000 различных файлов бэкапов? Или процедуру восстановления из одного из 100500 бэкапов (из прааавильного)?

FHS не нужен? Для дома для семьи работает решение в Applications или в Program\ Files. А для работы оно подходит? Что, идея работать устарела и в XXI веке не актуальна??? Systemd всё это исправит???

Не мог промолчать. Признаю, опоздал с коментариями.

Это единственная причина? ИМХО бред.

1)Это мелочь и практически незаметно, так как программ там не много

Мелочь, а всёж-таки приятно.

2)Некоторые программы, как ifconfig нужны обычному пользователю. Ввиду этого у многих настроено что обычный пользователь при автодополнении получает программы и из sbin

У многих настроено, у других - не настроено. Многие с другими могут ПО СВОЕМУ желанию меняться местами, как им заблагорассудится. Это есть такая небольшая гибкость.

Предлагается решить за всех отказаться от этой гибкости, что бы она ни значила для каждого пользователя. Вам пофиг? У Вас и так уже в PATH сидят все sbin? А у всех, думаете, так? Кто хотел - смог сделать так, как хотел.

Теперь - не сможет. Теперь будет так, как решил за него кто-то более умный.

допустим у меня есть пакет-лист системы. Большой. Сильно большой! И мне надо оттуда выпилить и загнать в отдельный файл все пакеты, начинающиеся на kde допустим. КАК МНЕ ИЗ ЭТОГО МНОГООБРАЗИЯ ВЫТАЩИТЬ ИХ ЗА 10 СЕКУНД, кроме как средствами grep, sed/awk, и cat?

Да, я не люблю сидеть за этим делом полдня и большинство ЛОРовцев будут со мной солидарны.

это всё давным-давно существует в Solaris. И так как является корпоративной ОС, работает на ура.

все хотел спросить - как солярка на десктопе? если можете, расскажите поподробнее.

Ну, если это таки один человек, да еще он же и root, то уж о su -c и sudo он, думаю, знает. А остальным «Марьиваннам» в /sbin таки ИМХО делать нечего.

А эээ напомните, ~/.config, ~/.local, ~/.cache они уже запилили? И, главное, выпилили-ли они ~/.* остальное говно? Мне вот насрать где лежит ifconfig и awk пока они есть в $PATH. Мне там делать нечего: есть yum и apt. А вот бардак в ~ меня просто бесит.