Разработчики дистрибутива Fedora Linux рассматривают (http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/1...) возможность перемещения всех имеющихся в системе исполняемых файлов в одну директорию. Иными словами, предлагается (https://fedoraproject.org/wiki/Features/UsrMove) размещать исполняемые файлы только в каталоге /usr/bin, а директории /bin, /sbin и /usr/sbin преобразовать в смволические ссылки, указывающие на /usr/bin. По аналогии предлагается упразднить /lib и помещать все системные библиотеки только в директории /usr/lib. В случае одобрения предложения, изменения могут вступить в силу уже в весеннем релизе Fedora 17.
Перенос всех файлов и библиотек в иерархию /usr открывает очень интересные перспективы: так как все необходимые для работы компоненты будут присутствовать в рамках одного дискового раздела, появляется возможность монтирования рабочей системы разом, обособленного использования нескольких разделов /usr для загрузки разных версий или состояний дистриб...URL: http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/1...
Новость: http://www.opennet.me/opennews/art.shtml?num=32194
c:\program files
:-)
Да, осталось только переименовать /usr/bin в /Program_Files
Для этого /opt есть...
>Да, осталось только переименовать /usr/bin в /Program_Filesтогда уже в /Program Files
>Да, осталось только переименовать /usr/bin в /Program_Filesа куда девать windows\\system32 ?
Смешно, но в винде там всё что можно лежит, а тут будут только бинарники
program files/bin ?
program files/lib ?
program files/share ?
не гоните, сударь.а вот opt - это и есть аналог програм файлс
В Windows как раз таки идет разделение, системные программы лежат в C:\Windows\, а пользовательские в C:\Program Files\, а также в тех папках (которые указывает сам пользователь).
P.S. По крайней мере, так было в Windows XP.
> В Windows как раз таки идет разделение, системные программы лежат в C:\Windows\,
> а пользовательские в C:\Program Files\Только что-то сразу после инсталла в C:\Program Files\ полно всякого хлама :)
> В Windows как раз таки идет разделение, системные программы лежат в C:\Windows\,
> а пользовательские в C:\Program Files\, а также в тех папках (которые
> указывает сам пользователь).
> P.S. По крайней мере, так было в Windows XP.В "Program Files" кладётся банально то, что легко отделить от системы. Это по-прежнему часть винды. Проще говоря, там лежит то, что разработчикам винды показалось удобнее и/или логичнее положить туда, и всё.
Хорошее разделение в Windows есть в другой области: Local Settings в пользовательском профиле. Казалось бы мелочь, но при грамотном использовании повышает скорость работы с сетевыми профилями (в AD). FreeDesktop.org двинулись в этом направлении, сделав ~/.local, но в никсах это смотрится несколько убого. Логичнее было бы /var/tmp с квотами, но и этот вариант не без подводных камней...
Увы, в Windows не всё так гладко.В "Program files" лежит то, что когда то было отдельными продуктами: IE, WMP. При этом DirectX, несмотря на то что является по сути отдельной "программой", находится в папке Windows. Мелкие программы, как calc, notepad, mspaint, .. лежат в Windows\System; справка по мелким программам - вперемешку с файлами с системной справкой. В последних версиях добавили папки "Common files" и "Uninstall Information", которые больше системные, чем программные (вспоминаем название - "Программные файлы" - "Program files").
Пользовательскую папку начали похабить ещё в ХР. Изначально она была вида "C:\Documents & settings\username\" и пользователь организовывал её по своему разумению (по мне так логичнее назвать её "C:\UserData\username\"). Сейчас в ней толпа виртуальных папок, вкл. AppData, в которую некоторые "умные" разработчики ПО предпочитают устанавливать свои программы. В "Моих документах" создают папки для своих файлов большинство серьёзного (?) ПО. В результате бардак и захламление. Майкрософт подливает масла в огонь, так программа синхронизации фотографий со SkyDrive синхронизирует файлы только из "Мои Изображения", предпочитая подключать к данной виртуальной папке реальные папки, делая из пользовательской папки хрен пойми что.
В результате диск C: фактически полностью стал системным диском и хранить на нём пользовательские данные год от года становится всё неудобнее. Этому способствует и появление в корне уродливых папок вида "Documents & settings", "PerfLogs", "MSOCache", и пр., хотя их можно было засунуть в "Windows" или "Temp".
> Увы, в Windows не всё так гладко.
> В "Program files" лежит то, что когда то было отдельными продуктами: IE,
> WMP. При этом DirectX, несмотря на то что является по сути
> отдельной "программой", находится в папке Windows. Мелкие программы, как calc, notepad,
> mspaint, .. лежат в Windows\System; справка по мелким программам - вперемешку
> с файлами с системной справкой. В последних версиях добавили папки "Common
> files" и "Uninstall Information", которые больше системные, чем программные (вспоминаем
> название - "Программные файлы" - "Program files").И я про то говорю: разделение, что куда, банально "исторически сложилось".
>[оверквотинг удален]
> программы. В "Моих документах" создают папки для своих файлов большинство серьёзного
> (?) ПО. В результате бардак и захламление. Майкрософт подливает масла в
> огонь, так программа синхронизации фотографий со SkyDrive синхронизирует файлы только
> из "Мои Изображения", предпочитая подключать к данной виртуальной папке реальные папки,
> делая из пользовательской папки хрен пойми что.
> В результате диск C: фактически полностью стал системным диском и хранить на
> нём пользовательские данные год от года становится всё неудобнее. Этому способствует
> и появление в корне уродливых папок вида "Documents & settings", "PerfLogs",
> "MSOCache", и пр., хотя их можно было засунуть в "Windows" или
> "Temp".А зачем хранить пользовательские данные на C:? unattend.txt наше всё. :) Хотя хвалить за такое "удобство" Microsoft не хочется, конечно. Впрочем, вроде бы, Win7 в каких-то редакциях позволяет задавать диск для размещения папки профилей, но могу и путать...
Каталог пользователя в Windows XP можно перенести в любое другое место - вроде бы открыть свойства каталога и задать новый путь при помощи волшебной кнопки, и он тут же будет перемещен. Уже не помню деталей, но я это делал разок. Но это конечно не оправдывает кучу хлама в documents and settings. Название, кстати, бестолковое - такое ощущение, что им чуть-чуть не хватило до варианта "Документы и всякая хня"
> Каталог пользователя в Windows XP можно перенести в любое другое место -
> вроде бы открыть свойства каталога и задать новый путь при помощи
> волшебной кнопки, и он тут же будет перемещен.Это вы про папку "Мои документы". Она лишь часть профиля.
> Уже не помню
> деталей, но я это делал разок. Но это конечно не оправдывает
> кучу хлама в documents and settings. Название, кстати, бестолковое - такое
> ощущение, что им чуть-чуть не хватило до варианта "Документы и всякая
> хня"В Win7 это теперь Users.
В ориентированных на среднячков дистрах делайте что хотите. Только, прошу, не трогайте дистры ориентированные на профессиональное использование. Разделеннние нужно. Возможно оно не особо нужно в какой-нибудь убунте ...
ну ка, продемонстрируй свое мнение, зачем же нужно разбиение?
> ну ка, продемонстрируй свое мнение, зачем же нужно разбиение?Потому что так жили наши деды, и мы будем жить так же, и внуки наши будут жить точно так же. Это наша деревня, знать не хотим никаких прогрессов.
> знать не хотим никаких прогрессов.А давайте в / сразу все вывалим, как в CP/M. И объявим это прогрессом :). Ведь история развивается по спирали.
> Иерархия должна быть стройной и логичной, иначе она теряет смысл.Тогда уж почему /usr/bin? А не просто /bin? И пачка симлинков - все еще больше запутает и сглючит, пожалуй.
>> Иерархия должна быть стройной и логичной, иначе она теряет смысл.
> Тогда уж почему /usr/bin? А не просто /bin? И пачка симлинков -
> все еще больше запутает и сглючит, пожалуй./Boot
/Boot/Applications
/Boot/Library
/Boot/Data
/Boot/Desktop
/Boot/Documents
/System
/System/Applications
/System/Library
/System/Data
/System/Desktop
/System/Documents
/Соmmon
/Common/Applications
/Common/Library
/Common/Data
/Common/Desktop
/Common/Documents
/Private
/Вася
/Вася/Applications
/Вася/Library
/Вася/Data
/Вася/Desktop
/Вася/Documents
/Петя
/Петя/Applications
/Петя/Library
/Петя/Data
/Петя/Desktop
/Петя/Documents
/Shared
Haiku?
почти угадал :)
Наличие прописных букв в начале слов подсказывает, что их мало кто набирал руками
Не аргумент - макинтошников большие буквы не останавливают ;) Кстати, откуда иерерхия? На редкость логичное построение в плане распределения по дискам для современных условий.
Чтобы шаловливые ручки пользователей не запускали прог из /sbin и не жаловались на отсутствие прав рута
> Чтобы шаловливые ручки пользователей не запускали прог из /sbin и не жаловались
> на отсутствие прав рутаТрепотня это все.
Если пользователь догадался, как открыть консоль и ввести там команду ifconfig, то нагуглить приписку /sbin его пытливому уму явно не проблема.
>Трепотня это все.
>Если пользователь догадался, как открыть консоль и ввести там команду ifconfig, то
>нагуглить приписку /sbin его пытливому уму явно не проблема.Да? Знаете ли, группа обычных юзверей не видит содержимое sbin. Нет надобности.
>ну ка, продемонстрируй свое мнение, зачем же нужно разбиение?Группа обычных пользователей не просматривает sbin. Риоднли запуск реально нужен? А в "убунтах" (пользовательская убунта на пользовательском ноуте) хоть всю /usr/*bin вываливайте в ~/.local/bin .
> Группа обычных пользователей не просматривает sbin.И что это дает? Можно убирать проверки на рутовые права и ставить suid root для находящихся там программ?
> Риоднли запуск реально нужен?
Да. Некоторым.
>>Группа обычных пользователей не просматривает sbin.
>И что это дает? Можно убирать проверки на рутовые права и ставить suid root для
>находящихся там программ?Разделение не дает смешения системых утилит. Запрет на их запуск дает мне спокойствие на случай обнаружения багов в системых утилитах. Чем больше утилит - тем больше вероятность нахождения багов среди утилит. Тот же эффект от недоступности информации о системых утилитах. Согласен что не панацея, но наличие оного лучше чем его отстутсвие, не так ли? Поэтому я пишу о значимости разделения в зависимости от областей использования дистрибутива (словосочетание "профессиональный подход" как бы намекает на это).
>>ну ка, продемонстрируй свое мнение, зачем же нужно разбиение?
> Группа обычных пользователей не просматривает sbin. Риоднли запуск реально нужен? А в
> "убунтах" (пользовательская убунта на пользовательском ноуте) хоть всю /usr/*bin вываливайте
> в ~/.local/bin .Что значит "не просматривает"? В PATH нет? На том же RH или Fedora ifconfig от пользователя прекрасно запускается через /sbin/ifconfig.
В openSUSE (видимо и в SLES) нужно писать /sbin/ifconfig
> ну ка, продемонстрируй свое мнение, зачем же нужно разбиение?Если мнение не сложилось, можно почитать
http://tldp.org/HOWTO/Partition/index.html
http://tldp.org/HOWTO/Multi-Disk-HOWTO.html
(упреждающий ответ тем, кто попытается не читая поржать над датами: а вы почитайте, ещё спасибо скажете, даже если виндузятники)
Главное чтобы слово ПРОФЕССИОНАЛ в зубах не застревало.
За Федорой поятнутся все остальные. А потом и в LSB это зафиксируют.
лолчто?
За Федорой потянутся все остальные, по крайней мере rpm-based дистрибутивы, чтобы не нарушать совместимость и чтобы можно было без большого гемора копиластить оттуда пакеты. В deb-мире всё сложнее. Космонавт тоже вроде не против, но он зависит от дебиана и, думаю, не будет радикально ломать с ним совместимость и увеличивать себе объём работы.
За Федориным горем ?
Да, федорино горе - это общее горе. Из него все нововведения со временем попадают в остальные дистрибутивы. Те же PulseAudio и systemd. Так что и Debian тоже примет эти изменения, не сомневайтесь. Примеры уже имеются - перенос правил udev из каталога /etc/udev/rules.d/ в каталог /lib/udev/rules.d/, а в /etc/udev/rules.d/ остались только изменённые или настроенные вручную правила.
Это все правда. /run уже в арче.
> За Федорой поятнутся все остальные. А потом и в LSB это зафиксируют.Ну главное - чтобы не в FHS
>Смотря в какой области. Вот, например, для профессионалов в IT тут ничего страшного нет - просто избавление от бессмысленного ритуала и добавление новых возможностей.А вот для профессионалов в области рассуждения о том, как правильно жить - действительно, довольно вредное и опасное нововведение.
Что-то личное? Я вижу смысл в разделении на "важных" системах. Вы, по-видимому, нет. Еще вопросы?
>> Разделеннние нужно.
>Правильно, а аргументы - не нужны.Читайте ветку - там есть мои ответы на вопрос почему у меня такая позиция. Остается только вопрос согласия с моей позицией. Но это и другой вопрос и малозначимый, так как каждый волен по-своему настраивать свое окружение.
Не потянуться, лично меня вполне устраивает свой старенький дистр ASPLInux Cobalt 14. И корневые разделы тоже. А что касается, что "все пользователи потянуться за Fedora" так это вряд ли. Fedora 15 еще не устранила баги в своем дистре, а уже клепает Fedora-17. На мой взгляд, лучше бы доделали то, что есть, а уже потом клепали бы себе Fedora 17.P.S. Лично меня не волнуют дистрибутивы, которые в свою очередь используют "облачные технолонии" (наподобие Мандривы 2011), мне, как пользователю важно то, чтоб была возможность настроить все приложения, папки, игры и редакторы по своему усмотрению. А вот менять уже сложивжуюся корневую систему, смысла не вижу.
М-дэ. Раз уж сломали независимость от /usr, то следующий шаг, конечно, логичен. Но чем-то мне это напоминает старую байку (которая вроде как и не байка) времён застоя:На карандашной фабрике было внесено рацпредложение: ведь никто не стачивает карандаш до конца - так зачем графит класть по всему стержню? Можно сэкономить несколько сантиметров более дорогого материала. Рацпредложение было принято в производство.
Через эн месяцев на другом совещании было внесено ещё одно рацпредложение: у нас в карандашах есть часть, которой никто никогда не сможет рисовать, потому что в ней нет графита - так давайте её уберём и сэкономим несколько сантиметров дерева! Рацпредложение тоже было принято в производство...
Ну так это типичный ход развития событий в Linux. Вместо того чтобы чинить обратно независимость от /usr, давайте сделаем помойку и не будем больше вспоминать о том, зачем, собственно, было сделано разделение.
Ну хоть бы что-то с этим колхозом директорий сделали!А вообще мне нравится структура как в http://gobolinux.org. Но пока до этого дойдут...
> Ну хоть бы что-то с этим колхозом директорий сделали!
> А вообще мне нравится структура как в http://gobolinux.org. Но пока до этого
> дойдут...там это сделано ужастнейшим костылем. нет, пусть уж лучше остается как есть пока не придумают что-нибудь лучше
Неважно как это реализовано, важно то, что идея хорошая (правильная). Мне понравилось.
Структура каталогов сложилась в Линуксе исторически. Видимо, редхатовцы не хотят ломать её радикально, как GoboLinux, но хотят упростить и сделать нечто подобное GoboLinux (а точнее подобное винде, т.к. Gobo взял аналог структуры папок из винды).
> Ну хоть бы что-то с этим колхозом директорий сделали!Угу, фермерское хозяйство девяностых.
> А вообще мне нравится структура как в http://gobolinux.org.
> Но пока до этого дойдут...А мне не нравится, вплоть до причисления додумавшихся к латентным виндузятникам. Хотя, возможно, до них когда-то действительно дойдёт.
>> Ну хоть бы что-то с этим колхозом директорий сделали!
> Угу, фермерское хозяйство девяностых.
>> А вообще мне нравится структура как в http://gobolinux.org.
>> Но пока до этого дойдут...
> А мне не нравится, вплоть до причисления додумавшихся к латентным виндузятникам.
> Хотя, возможно, до них когда-то действительно дойдёт.+1. Подобные идеи могут выдвигать только те, кто не понимает зачем так было задумано.
Этого "зачем" уже много лет нигде кроме эмбеддед не видели, не надо ляля
А мне нравится, ну почти. По крайней мере идея нормальная. Длинный имена каталогов с большой буквы это конечно явный баг :).Не вижу чем переход к такой структуре помешает разделить пользовательское и системное ПО, только легче станет. Для восстановления системы гораздо лучше IMHO использовать рам-диск. Разделение доступа, опять же по-моему скромному мнению, лучше поручить системам а-ля AppArmor и другим подобного типа определяющим правила доступа по пути, кстати при переходе к подобной структуре правила должны стать заметно проще, ведь достаточно описать права одной директории и наследовать их для всех дочерних объектов, нежели описывать права для каждого (важного) файла пакета.
И мейнтейнерам жить должно стать легче (хотя Михаилу виднее), ведь по-сути стандарт не описывает (IMHO) досконально структуру ФС, а соответственно расположение файлов программ различается от дистриба к дистрибу, причем иногда существенно. При этом соответственно каждый мейнтейнер взяв от мейнстрима исходники занимается составлением/переписыванием правил определяющих где и что должно лежать, т.е. строит/переделывает "велосипед" (в некотором смысле).
Внутри директории программы очевидно стоит оставить все как есть, т.е. обычное юникс-дерево.
Единственное, что меня напрягает, решение в виде триллиона ссылок (хотя сейчас из-за обратной совмстимости этого наверное не избежать). Вопрос с вызовом бинарников и т.д., мне кажется (по крайней мере относительно исполняемых файлов) это должно решаться на уровне ФС, в ней все равно храняться все биты доступа. Нужно просто сделать хранилища, кеши, со списком исполняемых файлов, суид и т.д. И внести изменения в системные вызовы типа exec, которые будут искать по кешу если вызов сделан по относительному пути. Обновление кеша может происходить как по-требованию, так и автоматически при chmod.
По сложности IMHO это не превысит текущего решения с симлинками, но будет красивее.Кстати парочку симлинков при желании никто не мешает.
Почитал на wiki.
Надеюсь, такого ужаса я никогда не увижу в приличных дистрибутивах.
> Почитал на wiki.
> Надеюсь, такого ужаса я никогда не увижу в приличных дистрибутивах./run уже портировали, ждите изменений в FHS.
> А вообще мне нравится структура как в http://gobolinux.org.Если еще чуть развить, то вот класс-то можно будет сделать...
export PATH=/Programs/bash/4.1/bin/:/Programs/bzip2/1.0.6/bin/:/Programs/gzip/1.3.12/bin/:/Programs/tar/1.23/bin/:/Programs/grep/2.5.4/bin/:/Programs/make/3.82/bin/:/Programs/m4/1.4.14/bin/:/Programs/coreutils/8.12/bin/:/Programs/diffutils/2.8.7/bin/:/Programs/perl/5.12.1/bin/:/Programs/python/2.7.2/bin/:/Programs/Bash/3.0/bin/:/Programs/gcc/4.6.1/bin/:/Programs/xz/5.0.2/bin/:/Programs/sed/4.2.1/bin/:/Programs/file/5.09/bin/:/Programs/cpio/2.11/bin/:/Programs/patch/2.6.1/bin/:/Programs/slocate/3.1/bin/:.......
... и это только самое начало
В лупе можно обойти, например.
> В лупе можно обойти, например.А как весело в скриптах-то!
#!/Programs/Bash/4.1/bash
...Проапдейтил систему - вперед! Переписывай все скрипты! Праздник!
Можно сделать что-нибудь, чтобы подобный текст не растягивал верстку страницы?
> Можно сделать что-нибудь, чтобы подобный текст не растягивал верстку страницы?Так он и не растягивает, максимум до ширины экрана получается. Если это не так - выбросьте ваш браузер и используйте нормальный.
смотрите шире: можно что-нибудь сделать, чтобы никогда такого не увидеть?
> мне нравится структура как в http://gobolinux.org.Это тот который со своей структурой никому не нужен?
Parent Directory -
GoboLinux-013-i686.iso 09-Dec-2007 12:09 700M
GoboLinux-013-i686.i..> 09-Dec-2007 12:09 57
GoboLinux-014-i686.iso 28-Dec-2007 22:48 667M
GoboLinux-014-i686.i..> 28-Dec-2007 22:48 57
GoboLinux-014.01-i68..> 31-Mar-2008 02:25 671M
GoboLinux-014.01-i68..> 31-Mar-2008 02:25 60
Интересно...А /usr/local/bin тоже выпиливаем?
А как тогда разные версии юзать?
/opt/bin и /home/user/bin
> /home/user/binНе, не, не, только не это... Вы хотите превратить хомяк в свалку бинарников и библиотек, в то время как безопасность требует обратного (noexec на весь хомяк)?
> noexec на весь хомякФигня. Любой доступный юзеру файл он сможет запустить, скопировав его в /tmp и поставив права на исполнение
>> noexec на весь хомяк
> Фигня. Любой доступный юзеру файл он сможет запустить, скопировав его в /tmp
> и поставив права на исполнениеmount -o remount,noexec /tmp
ну или как вариант
mount -o remount,mode=1766 /tmp
> mount -o remount,noexec /tmpВы прослушали совет "как сломать пакетный менеджер и много чего еще".
>> mount -o remount,noexec /tmp
> Вы прослушали совет "как сломать пакетный менеджер и много чего еще".Круглыми сутками занимаешься апдейтами, тогда вам нужно:
find / -noleaf -exec chmod 7777 {} \;
Уверяю Вас, на высоконагруженом, сверхбезопастном сервере localhost
это не повредит безопасности государства и мировой экономике.
> Уверяю Вас, на высоконагруженом, сверхбезопастном сервере localhostА на всех остальных серверах обновления следует запретить. И cron, на всякий случай.
>> mount -o remount,noexec /tmp
> Вы прослушали совет "как сломать пакетный менеджер и много чего еще".Не совсем ломается. Обламывается запускать скрипты, но в целом таки работает, несмотря на ругательства.
> Не совсем ломается. Обламывается запускать скрипты, но в целом таки работает, несмотря
> на ругательства.Ах да. Не отработавшие postinst и postrm скрипты пакетов - право же, какая мелочь.
Почему же тогда меня не ломает выполнять:
sudo mount -oremount,exec /tmp
sudo mount -w -oremount /boot
перед выполнением:
sudo aptitude full-upgrade
???
И пальцы до сих пор не отвалились!
>> mount -o remount,noexec /tmp
> Вы прослушали совет "как сломать пакетный менеджер и много чего еще".Да ну? Из этого "много чего" сходу припоминается разве что mc -- кстати, надо будет проверить да зафайлить, раз уж он ожил.
Ликбеза ради, в линуксе есть что-то аналогичное per_user_tmp=yes из NetBSD?
> Ликбеза ради, в линуксе есть что-то аналогичное per_user_tmp=yes из NetBSD?А Xorg как работает с этой фичей?
> Ликбеза ради, в линуксе есть что-то аналогичное per_user_tmp=yes из NetBSD?Есть pam_mktemp на схожую тему. Про именно жёстко per user что-то тоже припоминается, но совсем смутно и экспериментальное.
/lib/ld-linux.so <binary> ?
> /lib/ld-linux.so <binary> ?:)
# /lib64/libc.so.6
GNU C Library stable release version 2.11.3 (20110203), by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for x86_64-suse-linux.
Compiled by GNU CC version 4.5.1 20101208 [gcc-4_5-branch revision 167585].
Compiled on a Linux 2.6.36 system on 2011-02-22.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.--
Чё с libc.so делать? :)
> /lib/ld-linux.so <binary> ?В цивилизованном мире этот чит против noexec-разделов уже давно не срабатывает.
я удивлен что это не Lennart Poettering предложил, автор /var/run > / и прочих прелестей отхода от Unix
Чего они там курят интересно? То из-за systemd стало невозможным /usr выносить на отдельный раздел, теперь вот еще одна "блестящая" мысль.> В настоящее время дистрибутив нереально загрузить без /usr (/usr монтируется из
> initramfs до запуска процесса инициализации и содержит необходимые для загрузки
> компоненты), что в сочетании с распространением практики разбиения диска на один
> большой раздел и подготовкой установочного образа в виде Live-системы, позволяет
> отнести к анахронизмам разделение бинарных файлов по разным частям файловой системы.Это вообще проблемы Fedora. Я вот помню когда то ли Gentoo, то ли Arch использовал, они прекрасно работали (и грузились) в однопользовательском режиме без /usr.
А когда-то мир был плоским...
Мир не был плоским, а систему, при определённом допиле можно и сейчас заставить так работать. Пример - всякие embedded-устройства.
> Мир не был плоским, а систему, при определённом допиле можно и сейчас
> заставить так работать. Пример - всякие embedded-устройства.Embedded-устройства - это как раз пример объединения /usr и / (с той разницей, что там обычно /usr/* переезжает в корень, а не наоборот). Именно потому, что в условиях ограниченных ресурсов бессмысленные ритуалы отметаются довольно быстро.
Как интересно! Почему же тогда:$ ssh root@192.168.0.1 -p35700
Enter passphrase for key '/media/KEY/.ssh/id_dsa':BusyBox v1.15.3 (2011-07-07 02:30:22 CEST) built-in shell (ash)
--snip--
Backfire (10.03.1-RC5, r27608) --------------------------
* 1/3 shot Kahlua In a shot glass, layer Kahlua
* 1/3 shot Bailey's on the bottom, then Bailey's,
* 1/3 shot Vodka then Vodka.
---------------------------------------------------
root@OpenWrt:~# ls -l /
-rw-r--r-- 1 root root 0 Mar 27 02:44 1000
-rw-r--r-- 1 root root 0 Mar 27 02:44 262143
drwxr-xr-x 2 root root 641 Jul 15 2011 bin
drwxr-xr-x 5 root root 920 Mar 27 02:44 dev
drwxr-xr-x 12 root root 0 Mar 28 00:52 etc
drwxr-xr-x 4 root root 0 Jul 15 2011 lib
drwxr-xr-x 2 root root 3 Jul 15 2011 mnt
drwxr-xr-x 7 root root 0 Jan 1 1970 overlay
dr-xr-xr-x 45 root root 0 Jan 1 1970 proc
drwxr-xr-x 16 root root 211 Jul 15 2011 rom
drwxr-xr-x 3 root root 0 Mar 27 03:01 root
drwxr-xr-x 2 root root 629 Jul 15 2011 sbin
drwxr-xr-x 11 root root 0 Jan 1 1970 sys
drwxrwxrwt 8 root root 240 Apr 9 05:52 tmp
drwxr-xr-x 7 root root 0 Jul 11 2011 usr
lrwxrwxrwx 1 root root 4 Jul 15 2011 var -> /tmp
drwxr-xr-x 4 root root 67 Jul 13 2011 www
root@OpenWrt:~#ЗЫ: не стоит валить все embedded в кучу.
А можно посмотреть на "ls -l /usr" ?
root@OpenWrt:~# du -sh /usr/*
190.5K /usr/bin
2.1M /usr/lib
1.7M /usr/libexec
2.4M /usr/sbin
151.0K /usr/shareroot@OpenWrt:~# du -sh /bin /sbin
562.0K /bin
124.5K /sbinВ основном ссылки на /bin/busybox, но весь дополнительный софт замещает ссылки оригинальными программами. Вот к примеру:
root@OpenWrt:~# ls -l /usr/sbin/
lrwxrwxrwx 1 root root 13 Jul 15 2011 80211stats -> madwifi_multi
lrwxrwxrwx 1 root root 13 Jul 15 2011 ath_info -> madwifi_multi
lrwxrwxrwx 1 root root 13 Jul 15 2011 athchans -> madwifi_multi
lrwxrwxrwx 1 root root 13 Jul 15 2011 athkey -> madwifi_multi
lrwxrwxrwx 1 root root 13 Jul 15 2011 athstats -> madwifi_multi
lrwxrwxrwx 1 root root 17 Jul 15 2011 brctl -> ../../bin/busybox
lrwxrwxrwx 1 root root 17 Jul 15 2011 chroot -> ../../bin/busybox
lrwxrwxrwx 1 root root 17 Jul 15 2011 crond -> ../../bin/busybox
-rwxr-xr-x 1 root root 154604 Jul 7 2011 dnsmasq
-rwxr-xr-x 1 root root 193856 Jul 7 2011 dropbear
lrwxrwxrwx 1 root root 4 Jul 15 2011 hostapd -> wpad
-rwxr-xr-x 1 root root 186812 Jul 7 2011 ip
-rwxr-xr-x 1 root root 3685 Jul 15 2011 ipsec
-rwxr-xr-x 1 root root 54400 Jul 10 2011 iptables
-rwxr-xr-x 1 root root 86240 Jul 7 2011 iw
-rwxr-xr-x 1 root root 64128 Jul 7 2011 iwconfig
lrwxrwxrwx 1 root root 8 Jul 15 2011 iwgetid -> iwconfig
lrwxrwxrwx 1 root root 8 Jul 15 2011 iwlist -> iwconfig
lrwxrwxrwx 1 root root 8 Jul 15 2011 iwpriv -> iwconfig
lrwxrwxrwx 1 root root 8 Jul 15 2011 iwspy -> iwconfig
-rwxr-xr-x 1 root root 57925 Jul 15 2011 madwifi_multi
-rwxr-xr-x 1 root root 27135 Jul 11 2011 madwimax
-rwxr-xr-x 1 root root 261984 Jul 10 2011 pppd
lrwxrwxrwx 1 root root 17 Jul 15 2011 rdate -> ../../bin/busybox
-rwxr-xr-x 1 root root 222876 Jul 7 2011 tc
-rwxr-xr-x 1 root root 635524 Jul 11 2011 tcpdump
lrwxrwxrwx 1 root root 17 Jul 15 2011 telnetd -> ../../bin/busybox
-rwxr-xr-x 1 root root 42884 Jul 7 2011 uhttpd
-rwxr-xr-x 1 root root 1092 Jul 11 2011 update-usbids.sh
lrwxrwxrwx 1 root root 13 Jul 15 2011 wlanconfig -> madwifi_multi
lrwxrwxrwx 1 root root 4 Jul 15 2011 wpa_supplicant -> wpad
-rwxr-xr-x 1 root root 468320 Jul 10 2011 wpad
> Как интересно! Почему же тогда:Потому что это тролль или человек с крайне ограниченным опытом.
> Это вообще проблемы Fedora.Думаю, даже нескольких ленивых при... под... прохвесионалов оттуда.
> Я вот помню когда то ли Gentoo, то ли Arch использовал, они прекрасно работали
> (и грузились) в однопользовательском режиме без /usr.У меня домашний альт прекрасно себя чувствует с / и /home на зеркалах, а /usr и /var -- на параллельных кусках двух дисков. Да, на ноутбуке, большинстве серверных HN и в контейнерах отдельного /usr нет, но на десктопе я от него по фантазиям левой пятки какого-нибудь разгильдяя отказываться не собираюсь.
> То из-за systemd стало невозможным /usr выносить на отдельный разделВсе строго наоборот. systemd как раз нормально работает в таких условиях, просто выводит предупреждение, что другие компоненты (например, udev) могут работать некорректно.
Но нынешние хомячки, как всегда, осуждают, не читая. "то ли он галоши украл, то ли у него украли... в общем, уголовник"
> Все строго наоборот. systemd как раз нормально работает в таких условиях, просто
> выводит предупреждение, что другие компоненты (например, udev) могут работать
> некорректно.Он не "просто выводит предупреждение", а тупо врёт, что "This is not supported anymore":
http://cgit.freedesktop.org/systemd/commit/?id=80758717a6359...Вместо этого можно было обучить systemd сразу после подъёма сети идти голосовать в багу на udev, и то пользы больше.
> Но нынешние хомячки, как всегда, осуждают, не читая.
(голос с задней парты) Да-да, конечно.
Не согласен с идеей. Ну может про /sbin и /bin ещё хоть как-то конструктивно (в убунте из-за sudo уже давно так), хотя достаточно просто получше отсортировать всё, то остальное - бред...
Согласен с предыдущим оратором. В нормальных дистрибутивах загрузка в single user mode возможна без монтирования /usr. Более того, прелесть выделения / на отдельный физический раздел заключается в том, что запись на него требуется редко (в идеале он может быть смонтирован read only), что дает некоторую гарантию того, что при сбое файловой системы /usr она может быть восстановлена без дискет/liveCD/etc...Наконец, даже в винде есть привилегированные и обычные пользователи. Деление на bin/sbin дает возможность упростить жизнь последним за счет сокрытия комманд, выполнение которых им все равно недоступно.
> Деление на bin/sbin дает возможность упростить жизнь последним за счет сокрытия комманд, выполнение которых им все равно недоступно.Запуск /sbin/ifconfig юзеру (относительно знающему юзеру) вполне доступен в режиме чтения, только набирать дольше приходится, чем хотелось бы. И если уж вы беспокоитесь о душевном состоянии большинства пользователей, то должны были вспомнить, что консоль для них - китайская грамота, так что они мало теряют.
ifconfig в арче упразднили, рекомендуют ip addr
> ifconfig в арче упразднили, рекомендуют ip addrОднако, ip тоже находится в /sbin.
iproute2-2.6.39:
SBINDIR=/sbin
ip/Makefile:
TARGETS=ip
install: all
install -m 0755 $(TARGETS) $(DESTDIR)$(SBINDIR)
> Наконец, даже в винде есть привилегированные и обычные пользователи. Деление на bin/sbin дает возможность упростить жизнь последним за счет сокрытия комманд, выполнение которых им все равно недоступно.А вот это мне никогда не нравилось. Дело в том что в sbin валяется куча бинарей которые обычный пользователь может запускать. Тот же банальный ifconfig.
Не вижу абсолютно никакого смысла в "сокрытии" sbin от пользователя.Всегда во всех системах мне приходится добавлять своему юзеру /sbin:/usr/sbin:/usr/local/sbin в PATH руками, потому что кто-то зачем-то "сокрыл" от меня их.
"В настоящее время дистрибутив нереально загрузить без /usr (/usr монтируется из initramfs до запуска процесса инициализации и содержит необходимые для загрузки компоненты)" -- кто бы им объяснил, что это баг и его надо фиксить, а не объявлять фичей... я пробовал, но похоже, в этом месте у Леннарта действительно не всё с головой в порядке: http://lwn.net/Articles/431111/
> у Леннарта действительно не всё с головой в порядке-- тоже мне открытие века.
>> у Леннарта действительно не всё с головой в порядке
> -- тоже мне открытие века.Тоже мне выдёргивание цитат из контекста.
Кроме "в этом месте", у него есть и другие -- а его ранние проекты вроде ifplugd у меня вообще были в списке образцовых апстримов.
>ifplugdЭто тот который «Работает в двух режимах бибикает и все портит»? Его отучили уже пищать без повода при загрузке?
Давайте смотреть правде в глаза Леннарт не написал ни одной строки хотя бы среднего кода. Ни одной.
> Это тот который «Работает в двух режимах бибикает и все портит»? Его
> отучили уже пищать без повода при загрузке?
> Давайте смотреть правде в глаза Леннарт не написал ни одной строки хотя
> бы среднего кода. Ни одной.Если заменить "ifplugd" на "Linux", а "Леннарт" на "Линус" - ни истинность утверждения, ни мотивация его автора не изменятся.
Давайте смотреть правде в глаза: собака лает, а караван идет :)
>>ifplugd
> Это тот который «Работает в двух режимах бибикает и все портит»?Только в неумелых руках, как и редактор: -b не отменяли (у меня на альте, по крайней мере).
> Давайте смотреть правде в глаза
Давайте.
> Леннарт не написал ни одной строки хотя бы среднего кода. Ни одной.
Предлагаю пари: или Вы предъявляете свой интересный код хорошего качества, а я берусь его посмотреть и упаковать в альт -- или Вы балаболка.
Ранние проекты у него были неплохие. Сейчас, похоже, звёздная одолела. Это проходит.
> Только в неумелых руках, как и редактор: -b не отменяли (у меня
> на альте, по крайней мере).Да можно уже не пеарить этот альт..
>> Леннарт не написал ни одной строки хотя бы среднего кода. Ни одной.
> Предлагаю пари: или Вы предъявляете свой интересный код хорошего качества, а я
> берусь его посмотреть и упаковать в альт -- или Вы балаболка.Ты в свой альт можешь хоть чорта рогатого упаковывать, мне до одного места, я слава богам использую более другой дистр.
> Ранние проекты у него были неплохие. Сейчас, похоже, звёздная одолела.
> Это проходит.Ты в зеркало посмотри, мож тоже пройдет, звездоносец опеннета..
>> Только в неумелых руках, как и редактор: -b не отменяли (у меня
>> на альте, по крайней мере).
> Да можно уже не пеарить этот альт..Я привёл точку данных, которая была под рукой; могу ещё на дебиане с опенсузей глянуть, если хотите (и вряд ли найду отличие).
К жёстким данным перешёл потому, что ещё днём начало закрадываться подозрение по нескольким косвенным признакам, что один полуграмотный гиперактивный аноним и два-три местных виндузятника не просто так тут дурдомовский хоровод такой ладный устроили.
[...]
Слушайте, мне лень с Вами ругаться. Пусть то, что Вы написали, оценит кто-нибудь другой.
Мне понравился список программ требующих /usr при загрузке:
PulseAudio, NetworkManager, ModemManager, gnome-color-manager, D-Bus, CUPS, Plymouth
„Качество“ программ из вышеприведенного списка давно стало притчей во языцех.
> Мне понравился список программ требующих /usr при загрузке:
> PulseAudio, NetworkManager, ModemManager, gnome-color-manager, D-Bus, CUPS, Plymouth
> „Качество“ программ из вышеприведенного списка давно стало притчей во языцех.При том, что PulseAudio и NetworkManager многие либо не ставят, либо сносят в первую очередь, Plymouth суть ненужный хлам, а от gcm и d-bus нет никакого толку без иксов и пользовательской сессии. Что естьModemManager не в курсе, т.к. не использую, равно как и CUPS (этот по той причине, что принтера нет).
> При том, что PulseAudio и NetworkManager многие либо не ставят, либо сносят
> в первую очередь, Plymouth суть ненужный хлам, а от gcm и
> d-bus нет никакого толку без иксов и пользовательской сессии. Что естьModemManager
> не в курсе, т.к. не использую, равно как и CUPS (этот
> по той причине, что принтера нет).Могли бы сказать короче и проще: "в теме не разбираюсь, но всех решительно осуждаю".
> Могли бы сказать короче и проще: "в теме не разбираюсь, но всех
> решительно осуждаю".Ну как это не разбирается, когда разбирается?
Чуваки из Fedora объясняют нам, что система без /usr не загрузится, потому что там стоят жизненно важные программы (дальше перечисляются названия), поэтому смысла в отдельных каталогах /usr/bin и /usr/sbin нет.
А тут есть человек, который всем этим перечисленным мусором не пользуется и его система нормально грузится без этого хлама. Это контрпример, который опровергает истинность заключения федоровцев.
> кто бы им объяснил, что это баг и его надо фиксить,Ну объясните мне для начала, а то я не понимаю, почему сразу баг.
Лично я не вижу никаких причин делать корень автономным от /usr.
> Лично я не вижу никаких причин делать корень автономным от /usr.В старой схеме:
/usr не работает - что ж, со скрипом и треском загрузимся с корня, если повезет.
/ не работает - сосем лапу и ищем загрузочный сидюк/флешку.В новой схеме:
/ не работает - пофигу, останемся с тем, что нам скрипты из initrd по-быстрому сляпали, главное, /usr-то есть. А конфиги - хрен с ними, сейчас бы починиться.
/usr не работает - сосем лапу и ищем загрузочный сидюк/флешку.Итак, минусов не видать. А вот плюсы, описанные в новости (например, возможность делать кучу компов с общим /usr), весьма вкусны.
В старой схеме была возможность запихать /, /etc и ещё чего-нить на CF карту и физически щёлкнуть на ней переключатель в RO (переключая в RW только в случае обновления или изменения конфигов ручками) то терь обломайтесь по определению. Да да иногда и такое нужно.
Вот такая вот схема.
> ... это стало еще проще и удобнее (отдельно рулится RO на конфиги
> - /, отдельно на обновления - /usr).Вы перечитайте что я пишу. Базовая система вместе с ядром и конфигами и ещё парой вещей лежит на RO (физически RO) флэше.
> Чего-чего? А если подумать?
> Вы вообще понимаете суть предлагаемых изменений, или сразу бросились обсуждать, прочитав
> лишь заголовок?Я то прекрасно понимаю. Прочитайте ещё разок о чём я говорю.
> Ну если вы все прекрасно понимаете, то объясните мне, как именно обсуждаемые
> изменения помешают изложенной вами схеме.Тем что теперь на флэш мне придётся переть over гигабайт вместо сотни метров.
Если что у себя в Wive-NG-RTNL использую именно такую схему как озвучивают федоровцы. Причём изначально. И уже всё опробавно и проверено.
Для встраиваемых решений где всё упихано в 4-8Мб флэша одним разделом сиё оправдано.
Для реально работающих у меня решений описанных выше (CF Card 128-256Мб) с новой схемой это становиться невозможно или как минимум бесполезно. Ибо все сервисные тулзы аля fsck окажуться в одной помойке с ещё овер гигабайтом софта. В итоге придётся переть всю эту помойку на CF где оно нафиг не нужно, либо забыть о такой схеме в принципе. Тот же бардак
как я понял ожидает и библиотеки.Продемонстрируйте где ошибся, желательно без теоритезирования на живой конфигурации.
Нет уж, нафиг такое счастье, вместе с initrd который в моей схеме вообще бесполезная сущность.
> Всем бинарникам и либам - что ж, придется тащить весь /usr,а вы
> как думали?А нахрена мне весь /usr если мне по уши было достаточно тех бинарей что были в /bin /sbin ? А терь из-за товарищей из федогоря я должен буду тащить весь /usr ? Нет - спасибо, без них проживём.
> Простите, не понимаю сути ваших претензий. Вы считаете, что некоторые бинарные файлы
> бинарнее других, и поэтому на них надо ставить RO, а на
> остальные - не надо?1) Я считаю что базовая система включая ядро, glibc модули ядра, утилиты восстановления должны лежать в RO и ни при каких условиях недопустима даже теоретическая возможность модификации или подмены например одного из модулей ядра (кстати это требования прописаны во внутренних документах и более чем логичны).
2) Я считаю что взлететь и получить тот же fsck я должен независимо от живости всего остального.
3) Я решаю вполне определённые задачи и они решаются штатными средствами которые предполагается выкинуть.
>Что ж, никто не запрещает вам наплодить
> кучу каталогов и файловых систем, раскидать по ним файлы, прописать их
> в PATH и считать эту схему очень удобной :)Ой не смешите.
1) Удобство далеко не всегда основной критерий (мы не о локалхостах говорим однако)
2) Ничего плодить не нужно, всё что нужно предусмотрено FHS который предлагается изувечить
> Но людям с не столь извращенным мышлением удобнее сортировать по более простым
> критериям - "здесь бинарники, здесь конфиги, а здесь - логи".Ну дык никто не мешает им слить всё в кучу и наплодиь симлинков =)) Ну или на крайний случай уйти назад в винду =)
> То есть, вы полагаете, что
> а) ядро и glibc нельзя обновлять ни при каких обстоятельствах
> б) а на все остальные бинарники пофиг - пусть их правит кто
> хочетВы вообще читаете что я пишу? О обновлении сказано выше было. Будьте внимательнее.
> Это вам может гарантировать только live-носитель.
Это прекрасно гарантирует CF карта в RO а надо будет 10ть CF карт которые на лету заменяются (да да вместе с корнем, всё давно написано и отлажено).
> Не знаю, какие задачи вы там решаете. А вы упорно не хотите
> говорить.Не имею права.
> Да я уже понял, что для вас основной критерий - чтобы правой
> щекой через левую пятку :)Когда будете на моём месте вот тогда и будете рассуждать. Пока советую воздержаться от критики. Вы просили пример который не вписывается в то что творят федогористы - я привёл. Не нравиться? Ну эт ваше личное дело. Я для себя поставил ещё одну галочку "против" федогоря.
> Ага, а автомобиль - это жестоко изувеченная карета.
Не передёргивайте. На мой взгляд автомобиль это FHS. А вот федогоревцы из него пытаются сделать не то карету не то телегу.
> Судя по вашим критериям "привальной организации", идти на винду стоит именно вам.
> Там тоже любят творить фигню, объясняя это невнятными выкриками.О как, т.е. FHS фигня? Вы бы поменьше бы чепуху бы пороли. Поймите уже что мир гораздо сложнее чем вам кажется и задач гораздо больше нежели хотелось бы. В данном случае я ещё раз говорю, устраивать мешанину из стройной FHS на мой взгляд полная дурость и привнесёт лично мне и людям решающим подобные задачи больше проблем нежели пользы.
Там где такой подход оправдан он давно мной используется (см Wive-NG). Так что не надо тут всех под винду с их "мы все равны не дать не взять" грести.
Пусть федогоревцы развлекаются как хотят, это их проблемы. Решение на мой взгляд дико неудачное.
Хочется поспорить - значитхватит теоретизировать и начните применять подход который вы так рьяно защишаете. И не только на локалхосте или говнороутерах.
В общем смысла дальше флудирастить нет ибо работать нужно. Через годик-два посмотрим что из этого всего вышло. Благо я сильно в сомнениях что такой подход переймут все остальные (надеюсь этого не будет, точнее более чем уверен).
> Не имею права.достаточно сказать волшебные слова "embedded development". подробности ни к чему :)
> достаточно сказать волшебные слова "embedded development". подробности ни к чему :)Какраз встройка тут не причём в стройке см выше.
> Вы вообще читаете что я пишу?Он демагог и не за тем пришёл, не трать время.
> Итак, минусов не видать.А теперь обратите внимание на вид, открывающийся справа: это размер /usr+/ по сравнению с размером /. Чуть дальше можно будет оценить воронку от прямого попадания бэда в /var.
Это если даже Multi-Disk HOWTO не почитать и вообще интересоваться только десктопами...
> А теперь обратите внимание на вид, открывающийся справа: это размер /usr+/ по сравнению с размером /Строго похрен.
Много ты видел систем где /usr находится на отдельном физическом носителе по сравнению с /? Я ни одной. Отдельные разделы не считаются, естественно.> Чуть дальше можно будет оценить воронку от прямого попадания бэда в /var.
А что это имеет общего с объединением / и /usr? Или (испуганно) кто-то имеет отдельный /usr, но неотделенный от корня /var?
> Это если даже Multi-Disk HOWTO не почитать и вообще интересоваться только десктопами...
Нерелевантно. ну не создают / и /usr нагрузку в наши времена (/srv и /var, да), равно как и не повышают надежность. Ограничения на размер тоже безразличны, когда ты видел в последний раз root _tape_?
>> А теперь обратите внимание на вид, открывающийся справа: это размер /usr+/
>> по сравнению с размером /
> Строго похрен.Не скажи.
> Много ты видел систем где /usr находится на отдельном физическом носителе по
> сравнению с /? Я ни одной. Отдельные разделы не считаются, естественно.В трёх метрах вон примерно такая стоит -- если RAID1 с / согласишься считать более отдельным физически, чем один из дисков в нём, на котором в т.ч. /usr.
Ещё порой ставил /usr вперёд: тогда не так страшен промах вида hda вместо hda1 (и однажды именно эта предосторожность и спасла, когда надумал извернуться и засунуть честный PC-DOS 7 на расширенный раздел, а он снёс первый попавшийся). Сейчас обычно вперёд своп по той же главной причине.
>> Чуть дальше можно будет оценить воронку от прямого попадания бэда в /var.
> А что это имеет общего с объединением / и /usr?См. вид, открывающийся справа.
Заметь, /+/usr по гигу на всё про всё у меня бывают, там в /usr практически ничего ценного нет и отделять его смысла соответственно тоже: диаметр мишени особо не уменьшится.
--- сервер ---
791M / # CF: совмещённый
114M /usr474M / # SAS: совмещённый
115M /usr--- десктоп ---
7.6G /
5.4G /usr # ноут: совмещённый с /568M /
6.6G /usr # десктоп: отдельныйУ ноута /usr тоже совмещённый, поскольку точно есть батарейка (без электрика и уборщицы по дороге до материнки) и эксперименты с oops'ами провожу нечасто.
На десктопе contra для меня тут одно, но есть: дежурный бэкап системы чуточку (а восстановление -- чуть больше) усложняется.
> Или (испуганно) кто-то имеет отдельный /usr, но неотделенный от корня /var?
Не, ну горячие данные первей отцеплять надо, кто ж спорит.
>> Это если даже Multi-Disk HOWTO не почитать и вообще интересоваться только десктопами...
> Нерелевантно.Категорично.
> ну не создают / и /usr нагрузку в наши времена (/srv и /var, да),
> равно как и не повышают надежность.Саш, ну ты-то должен понимать, что "мало" не значит "вовсе нет".
Нагрузка на /usr на терминальном сервере с тонкими клиентами или на файловом с толстыми бывает приличной и в наши дни. MTBF HDD довольно велик и шанс нарваться именно на вылезший до конца бэд (а не похоронный стук головой) субъективно тоже понизился -- но не до нуля. Что с SSD, пока дружно выясняем на собственном лбу.
BTW у тебя сейчас шляпы под рукой нет? Они /boot до сих пор предлагают дефолтно отдельный, а /home на корне?
> Ограничения на размер тоже безразличны, когда ты видел в последний раз root _tape_?
Этих в работе не застал, только уже отключенные шкафы (ну или терминалы, но там в машзал не совались, да и тортовницы там уже были, наверное).
PS: а ещё большой корень провоцирует загаживать его всяким хламом. Правда, сделанный без двойного запаса может оказаться проще угробить, чем dist-upgrade'нуть, но это ж тоже понимать надо...
> > Много ты видел систем где /usr находится на отдельном физическом носителе по
> > сравнению с /? Я ни одной. Отдельные разделы не считаются, естественно.
> В трёх метрах вон примерно такая стоит -- если RAID1 с / согласишься считать более отдельным физически, чем один из дисков в нём, на котором в т.ч. /usr.Ух ты. А зачем?
Серьезно, я что-то подобное делал только в большой нужде, когда не мог отзекралить и /usr тоже.> ...
> Сейчас обычно вперёд своп по той же главной причине.Ну это прямо скажем не аргумент на отделение /usr, так как с этой же проблемой справляется -- как ты сам написал -- своп впереди или пустой раздел-заглушка, вообще не используемый
> Нагрузка на /usr на терминальном сервере с тонкими клиентами или на файловом с толстыми бывает приличной и в наши дни. MTBF HDD довольно велик и шанс нарваться именно на вылезший до конца бэд (а не похоронный стук головой) субъективно тоже понизился -- но не до нуля. Что с SSD, пока дружно выясняем на собственном лбу.
Ну файло файлсервера я бы тоже в /srv унес, а вот терминальные -- да, не подумал. С другой стороны, если /usr надо благодаря нагрузке уносить на более другой носитель, чего бы и / туда не унести? Много есть не просит. Быстрый и емкий, но небутабельный носитель? Видел такое один раз, какой-то сановский блейд с маленькой флешкой на пожарный случай и (проигнорированной) рекомендацией докупать еще сторадж-блейд. Но там бежал Солярис, которого было проще с iSCSI грузить чем отделить /usr.
Не, как ни крути мне все эти случаи кажутся маргинальными и решимыми с объединенным /+/usr.А насчет бэдов -- я это решал регулярным смарт-селфтестом и raid1 на все системные вещи. Действую по правилу "Данные -- бэкапить, конфиги -- бэкапить, систему -- зеркалить"
> BTW у тебя сейчас шляпы под рукой нет? Они /boot до сих пор предлагают дефолтно отдельный, а /home на корне?
шляпы нет.
>> В трёх метрах вон примерно такая стоит -- если RAID1 с / согласишься считать
>> более отдельным физически, чем один из дисков в нём, на котором в т.ч. /usr.
> Ух ты. А зачем? Серьезно, я что-то подобное делал только в большой нужде,
> когда не мог отзекралить и /usr тоже.Точно не скажу, но как-то несколько лет назад ту машинку неосторожно развалил по части загрузки, наивно предполагая, что уж у меня-то дома всегда найдётся с чего загрузиться. Эти два диска не особо большие, но достаточно шустрые, чтоб хотелось отрезать лишнее место от зеркального /home.
Заметь, я не спорю с пеной у рта, а говорю, что:
1) такие полтора процента случаев бывают;
2) вопрос элементарно решается в принципе (и давно решён в альте vsu@).(решён путём запуска udev с обкоцаным набором правил из initramfs ради доступа к корню, сам этот udev ко времени монтирования корня глушится, а с корня стартует уже полновесный -- при этом опять же в альте нет /usr/lib*/udev за отсутствием физического смысла, но отнести запуск основного udev на после монтирования локальных ФС тоже можно попробовать)
> Ну это прямо скажем не аргумент на отделение /usr, так как с
> этой же проблемой справляется -- как ты сам написал -- своп
> впереди или пустой раздел-заглушка, вообще не используемыйЯ тебе написал случай из жизни, только и всего. Для меня это аргумент, а ты можешь пожать плечами и сказать -- "ну теперь-то ты знаешь, что надо было просто своп вперёд" (хотя это тоже было известно заранее, только тогда первые цилиндры были быстрей). :)
>> Нагрузка на /usr на терминальном сервере с тонкими клиентами
> Ну файло файлсервера я бы тоже в /srv унес, а вот терминальные
> -- да, не подумал.Воот. Есть многое на свете, друг Горацио, о чём Леннарт тоже не догадывается. :)
> С другой стороны, если /usr надо благодаря нагрузке уносить на более другой носитель,
> чего бы и / туда не унести?Разумеется, я об этом подумал, когда писал.
> Не, как ни крути мне все эти случаи кажутся маргинальными
Вот этого слова я и ждал, спасибо. Так вот мне не по нраву списывание в маргиналов без как минимум веских технических обоснований (т.е. это "майнстрим" должен обосновывать, а не "маргиналы", если он берёт на себя такую инициативу и хочет быть достоин уважения).
> Лично я не вижу никаких причин делать корень автономным от /usr.Он уже давно сделан и работает; лично я не вижу никаких технических причин ломать эту автономность и устраивать лишний tight coupling.
>> Лично я не вижу никаких причин делать корень автономным от /usr.
> Он уже давно сделан и работает; лично я не вижу никаких технических
> причин ломать эту автономность и устраивать лишний tight coupling.причины есть (btrfs):
http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/1...
k) having all static, distro-specific, sharable OS in a single dir
makes snapshots of the OS independetly of its state and configuration
truly atomic. In a btrfs world doing 5 snapshots of /lib, /lib64,
/bin, /sbin and /usr instead of just one is not atomic, and hence
racy, and ugly, and boooh!..............
...and finally administrators have the major
benefits of the atomicity of the btrfs snapshotting, and for network and
especially container setups. And those three are absolute killer
features in my eyes.Lennart
--
Lennart Poettering - Red Hat, Inc.
> причины есть (btrfs):Спасибо, пока обхожусь ext3/ext4/xfs.
> http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/1...
> k) having all static, distro-specific, sharable OS in a single dir
> makes snapshots of the OS independetly of its state and configuration
> truly atomic. In a btrfs world doing 5 snapshotsВот если припрёт Именно Это, тогда его логика будет применима. А пока она, мягко говоря, не универсальна, но предлагается именно на таких правах (заметь, речь ведь идёт об оправдании развала работавшего, а не о предпочтении его неиспользования).
Собственно, попытки увода разговора в сторону от первопричины тоже некрасивы.
> And those three are absolute killer features in my eyes.
Абы только не в буквальном смысле слова.
>> причины есть (btrfs):
> Спасибо, пока обхожусь ext3/ext4/xfs.ключевое слово "пока". даже автор ext4 сказал, что это временный и промежуточный вариант, а btrfs - это наше светлое будущее. см. http://en.wikipedia.org/wiki/Btrfs
>> http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/1...
>> k) having all static, distro-specific, sharable OS in a single dir
>> makes snapshots of the OS independetly of its state and configuration
>> truly atomic. In a btrfs world doing 5 snapshots
> Вот если припрёт Именно Это, тогда его логика будет применима.так он же именно об этом и говорит. для чего ему надо все файлы в одном каталоге.
пока все обкатается на федоре, а потом будет использоваться в стабильной 7-й ветке системы, насколько я понимаю его мотивы и цели. он же сотрудник ред хата, а не просто так.> А пока она, мягко говоря, не универсальна, но предлагается именно на таких
> правах (заметь, речь ведь идёт об оправдании развала работавшего, а не
> о предпочтении его неиспользования).иногда создание нового подразумевает частичное разрушение старого.
иначе бы не было движения вперед.> Собственно, попытки увода разговора в сторону от первопричины тоже некрасивы.
так ведь GNU's Not UNIX. а это разделение на каталоги пришло с древнего юникса еще.
посмотри самый True UNIX - Solaris сейчас где находится и в каком состоянии.
не говоря уже о том, какая там жуткая свалка бинарного мусора в каталоге /etc.вроде бы верным путем шли товарищи - соблюдали обратную совместимость и традиции.
а что? где теперь их система и их традиции, и кому это все надо в конечном итоге?
Юзеры опять получат подводные камни от программ, которые не готовы к этому, как это было с переименовыванием интерфейсов eth0.Правильно, чихали на общие стандарты, давайте городить свои, прям как америкосы ей богу.. >_>
Так каталоги остаются и ссылки в них будут, в чем же проблема?
> Правильно, чихали на общие стандарты, давайте городить свои, прям как америкосы ей
> богу.. >_>А вы понимаете, что если всегда все делать по старинным стандартам, и никогда не пытаться их улучшить - прогресс просто остановится?
>> Правильно, чихали на общие стандарты, давайте городить свои, прям как америкосы ей
>> богу.. >_>
> А вы понимаете, что если всегда все делать по старинным стандартам, и
> никогда не пытаться их улучшить - прогресс просто остановится?Это-то да. Но есть стандарты переделывать без реальной необходимости (а именно необходимости что-то не видно, только "по-моему так будет клёво"), то проще забыть вообще про слово "стандарт".
Стандарт - это точка опоры. Опираясь на стандарт, все, кто им прямо или косвенно пользуется, экономят свои силы и время. Ломка стандарта - это всегда бардак, это проблемы по всей цепочке пользователей, это снижение реальной ценности стандартизируемого объекта.
Но, конечно, если Fedor'овцы хотят выстрелить себе в пятку, это их личное дело. :)
Конечно, в большинстве сущностей нет смысла, если ты их не понимаешь. И в большинстве правил нет смысла, если ты их не соблюдаешь.Разработчики Fedora не понимают, зачем сделано это деление бинарников, а потому и не придерживаются правил - куда и какой бинарник нужно класть. Они ведут себя, как слон в посудной лавке, ломают всю систему деления бинарников, а теперь оглядываются и говорят: "блин, да тут и так всё побито, давайте остатки посуды разобъём, чтобы всё было единообразно".
В /bin размещаются утилиты, которые необходимы для загрузки системы или для её восстановления. В /sbin располагаются те из предыдущих инструментов, для использования которых нужно быть пользователем root. В /usr/bin размещаются программы, которые используются в штатном режиме работы, когда всё исправно. В /usr/sbin располагаются программы, которые используются в штатном режиме работы, но для использования которых нужно быть пользователем root.
Примеры:
/bin - ls, cat, vi, dd, ping - необходимы при восстановлении системы, но права root не требуются.
/sbin - fsck, mount, umount, ifconfig, arp, fdisk - необходимы для восстановления системы, но требуются права root (или можно пользоваться и с правами обычного пользователя, но только в режиме просмотра).
/usr/bin - cal, audacious, mplayer, firefos - используются в штатном режиме работы, но права root не требуются.
/usr/sbin - dhcpd, postfix, squid - используются в штатном режиме работы, но требуются права root.
В прежние времена /usr можно было смонтировать по NFS и нормально работать, а в случае если /usr не смонтировался, можно спокойно исправить настройки сети, переразбить диски и т.п.
Смысла в делении bin/sbin особого нет, т.к. часто граница между этими программами бывает сложно различимой. Но такое деление очень удобно для автодополнения - у обычного пользователя в автодополнении не будут предлагаться те программы, которыми он _скорее всего_ не пользуется. Но если они ему понадобятся, он может либо исправить свой PATH, либо попробовать ввести команду, дополнив её каталогом /sbin или /usr/sbin.
А ещё, он может написать свои скрипты на shell или собрать простые программы только для себя, положить их себе в /home/user/bin и прописать их в свой PATH - они будут использоваться в автодополнении наравне с системными.
Это деление вполне разумно и его стоит придерживаться, а не объявлять его бессмысленным только потому, что ты его не придерживаешься.
> Смысла в делении bin/sbin особого нет, т.к. часто граница между этими программами
> бывает сложно различимой.Да уж. dd без рута, что выпить и не подраться!
> Да уж. dd без рута, что выпить и не подраться!Сам по себе dd - всего лишь обычная программа. Можно в 2 счета аналог накатать и не будучи рутом. Ы?
> В /bin размещаются утилиты, которые необходимы для загрузки системы или для её восстановления. В /sbin располагаются те из предыдущих инструментов, для использования которых нужно быть пользователем root.Ну почему все забывают про initrd? Сечас сложно найти Linux-систему, НЕ использующую его. Ведь сегодня считанные единицы перекомпилируют ядро самостоятельно под своё железо и, соответственно, драйверы, "которые необходимы для загрузки системы" лежат в initrd. Он УЖЕ есть! Ну и добавьте в него все "утилиты, которые необходимы для загрузки системы или для её восстановления" и "те из предыдущих инструментов, для использования которых нужно быть пользователем root".
> В прежние времена /usr можно было смонтировать по NFS и нормально работать ...
А в нынешние времена можно и / "смонтировать по NFS и нормально работать"! Бездисковые станции как раз и используют initrd для запуска сети и монтирования /.
> Это деление вполне разумно и его стоит придерживаться, а не объявлять его бессмысленным только потому, что ты его не придерживаешься.
При наличии initrd - не вполне разумно. Надо всё-таки понимать, для чего существует initrd, / и /usr.
Давайте вспомним классику: ядро (содержащее драйверы необходимых для загрузки блочных устройств) монтирует / и запускает /sbin/init. Дальше, в какой-то момент, монтируются прочие файловые системы, в т.ч. /usr, и запускаются некие процессы, расположенные в т.ч. в /usr/bin и /usr/sbin. Если что-то пойдёт не так, корень у нас всё равно смонтирован и, соответственно, доступен некий набор утилит для "ремонта". Ибо, если ядро не смогло смонтировать / - kernel panic.
21-й век: ядро монтирует в / содержимое Initial RAM disk'а и запускает /sbin/init, который, используя драйверы в /lib/modules и утилиты в /bin и /sbin RAM-диска, настраивает сеть, монтирует / и может много всяко-разного, включая, например, немерянные навороты device-mapper'а. И в последнюю очередь монтируется и подменяется корень. Если что-то пойдёт не так, корень у нас всё равно смонтирован и, соответственно, доступен некий набор утилит для "ремонта". Ну и что, что он на RAM-диске?
Вариант с initrd мощнее и гибче, что только подтверждается его повсеместным использованием. Так зачем нам ТЕПЕРЬ / отделённый от /usr?
> [...] в initrd. Он УЖЕ есть! Ну и добавьте в него все "утилиты, которые
> необходимы для загрузки системы или для её восстановления" и "те из
> предыдущих инструментов, для использования которых нужно быть пользователем root".Угу, только попробуйте до него достучаться после pivot_root. Это может быть осмысленным, если делать отдельную цель загрузки и отдельный спасательный initrd -- такое видывал.
>> В прежние времена /usr можно было смонтировать по NFS и нормально работать ...
> А в нынешние времена можно и / "смонтировать по NFS и нормально
> работать"!Ситуации разные, "в прежние времена" локальный / был rw, насколько понимаю (а NFS /usr -- ro). Сейчас Вы получите либо ro NFS /, либо его же с aufs/clicfs/tmpfs rw до ближайшего ребута. Либо каждому персональный /, но тогда смысл существенно теряется.
> 21-й век: [...] И в последнюю очередь монтируется и подменяется корень.
> Если что-то пойдёт не так, корень у нас всё равно смонтирован и, соответственно,
> доступен некий набор утилит для "ремонта". Ну и что, что он на RAM-диске?Что-то прекрасно может пойти не так уже после смены корня. Как при этом выпасть в шелл в initrd -- сходу не соображу (правда, и время уж позднее). Понятно, что флэшку/телефон не отменяли (и на самом деле _надеяться_ ни на какой корень или загрузчик со спасательными целями просто не стоит)...
>>> В прежние времена /usr можно было смонтировать по NFS и нормально работать ...
>> А в нынешние времена можно и / "смонтировать по NFS и нормально
>> работать"!
> Ситуации разные, "в прежние времена" локальный / был rw, насколько понимаю (а
> NFS /usr -- ro). Сейчас Вы получите либо ro NFS
> /, либо его же с aufs/clicfs/tmpfs rw до ближайшего ребута.
> Либо каждому персональный /, но тогда смысл существенно теряется.Ну, во-первых, совсем не обязательно, как показывает практика, иметь возможность записи в NFS-root и NFS-usr. А во-вторых, никто не запрещает Вам экспортировать и, соответственно, монтировать ресурсы (каталоги) по NFS в rw.
>> 21-й век: [...] И в последнюю очередь монтируется и подменяется корень.
>> Если что-то пойдёт не так, корень у нас всё равно смонтирован и, соответственно,
>> доступен некий набор утилит для "ремонта". Ну и что, что он на RAM-диске?
> Что-то прекрасно может пойти не так уже после смены корня. Как
> при этом выпасть в шелл в initrd -- сходу не соображу
> (правда, и время уж позднее). Понятно, что флэшку/телефон не отменяли
> (и на самом деле _надеяться_ ни на какой корень или загрузчик
> со спасательными целями просто не стоит)...Это верно, однако же "инициаторы инициативы" напоминают о существовании несметного количества спасательных и прочих Live-CD/DVD/USB.
Нет, я вовсе не настаиваю на том, что сабж - правильное решение. Но и однозначно неверным его тоже назвать нельзя. Технологии развиваются, проблемы, актуальные на момент определения существующей структуры файловой системы сегодня во многом неактуальны, как например объёмы дисковой памяти и возможности альтернативной загрузки.
Т.е. хочу сказать, что вопрос стоит обсудить, но ведь мы с Вами здесь этим и занимаемся...
> А вы понимаете, что если всегда все делать по старинным стандартам,
> и никогда не пытаться их улучшить - прогресс просто остановится?Ваш спам начинает напоминать мусор, который пора уже вычистить нафиг.
Потрудитесь доказать утверждение "улучшить" _перед_ тем, как плодить подобные ответы.
PS: и да, слово "прогресс" за довод не все принимают -- и даже для тех, кто принимает, требуется его предъявить, а не просто твердить про "улучшение".
А это не будет противоречить стандартам FHS?
> А это не будет противоречить стандартам FHS?Это приведет к выходу новой версии стандарта FHS.
Им на него класть. /var/run уже переместили в /run
> Им на него класть. /var/run уже переместили в /runКому "им"? Федоре, сусе, дебиану, убунте, или всем линуксам, вместе взятым?
Дык его тоже проапгейдят с Filesystem Hierarchy Standard до Fedora Hierarchy Standard
На деле новость неточная, т.к. хотят "убрать" и /lib{64}, что влечет за собой отказ от / полностью. Я не видел ни одного хауту где говорилось, что разумно отдавать целый раздел под /etc... Тем не менее, отказ от / влечет последствия для восстановления системы, т.к. размер /usr + /etc + / теперь увеличится с 350Мб до 2Гб+. Сейчас даже с крахом /usr, /var из-за того что в корне лежат весь минимум можно легко восстановить систему запустив банально fsck, в новом виде спасет только реинсталл. Не, может у ребят в Федора уже давно есть ноуты с двумя дисками под рейд 0 или делаются всегда бэкапы на точные зеркала, тогда их можно понять. И да, ладно бинарники в одном месте, но вот /lib/modules/kernel-x.xx.xx... Вера в Федорку все угасает :(Из 2 ссылки (пруф):
/
|-- etc
|-- usr
| |-- bin
| |-- lib
| `-- lib64
|-- run
|-- var
|-- bin -> usr/bin
|-- sbin -> usr/bin
|-- lib -> usr/lib
`-- lib64 -> usr/lib64
теперь по DHCP стало разливать еще неудобнее
можно было отдавать /bin /usr/bin и прочее, что относилось к "общим". и для локальных создавать отдельные папки, куда и ставить софт.Теперь придётся ***(наслаждаться) с чрутами и прочей херью, копируя по 10 раз одно и то же!
Для планшетников всё одинакого, что так, что эдак (куда 3й гном и катится).Херню делают в общем.
> отказ от / влечет последствия для восстановления системы, т.к. размер
> /usr + /etc + / теперь увеличится с 350Мб до 2Гб+Хм, у вас /etc и /usr - один раздел? Походу, вы ничего не поняли в предлагаемой схеме.
У меня в корне все кроме /usr, /var, /home, /boot и /opt (на ряде машин). Для этого достаточно 500Мб с излишком, зато рабочий /usr весит 10Гб и этот раздел постоянно шуршит при обновлениях, а не говоря уже про чтение всех либ и бинарников. Я хотел донести всего напросто то, что /usr в нынешнем виде читается и пишется гораздо чаще /, а следовательно при вырубании питания вероятность что слетит журнал /usr гораздо выше.
> Я хотел
> донести всего напросто то, что /usr в нынешнем виде читается и
> пишется гораздо чаще /, а следовательно при вырубании питания вероятность что
> слетит журнал /usr гораздо выше.Если отключить питание во время обновления - будет русская рулетка. Ядро обновляется довольно часто (даже в рамках поддержки безопасности), а значит, под ударом будут и /boot, и /lib (который на /).
А вообще, журнал на /usr может слетать сколько ему угодно - ничего невосстановимого там быть не должно по определению. Только файлы из штатных пакетов. А вот корень с /etc и /root - как раз может и должен содержать нетривиальные данные.
Вы когда-нибудь восстанавливали систему в случае сбоя питания? Кстати, зачем под / нужна журналируемая система, если там данные от силы пишутся раз в день? К несчастью для вас у меня не было случая когда рушился /, но было много случаев слета /usr и /var, в 90% случаев спасал обычный fsck, а также были случая невозможности восстановления этих разделов и тогда спасали mkfs.ext3 и mount. Такие вещи происходили и на боевых серверах, увы, время экономить надо не только свое, но и сотрудников, время "простоя" работы которых влетает по подсчетам руководства в нехилые деньги.
> Такие вещи происходили
> и на боевых серверах, увы, время экономить надо не только свое,
> но и сотрудников, время "простоя" работы которых влетает по подсчетам руководства
> в нехилые деньги.Именно поэтому, система управления /usr на боевых серверах должна быть централизованной.
Предлагаемая в сабже схема позволяет расширить эту систему на бинарники и либы, которые сейчас хранятся в корне, вместе с конфигами, что вынуждает городить костыли.
Итак, мы вернулись к моему незатейливому вопросу про раздел для /etc :) Видимо время облаков и затуманило разум людей, ведь клонированные сервера стоят в каждом офисе и в каждом доме и нет среди них "иного" или "уникального" сервера. Для таких серверов все централизованно и /usr и /etc и даже /boot у них одинаковые и даже интеррапты у этих серверов происходят в одно и тоже мгновение. Может стоит подумать прежде чем говорить такие умные слова, как "централизация"?
> Итак, мы вернулись к моему незатейливому вопросу про раздел для /etc :)
> Видимо время облаков и затуманило разум людей, ведь клонированные сервера стоят
> в каждом офисе и в каждом доме и нет среди них
> "иного" или "уникального" сервера.Я вам больше скажу: на самом деле, у всех компов с одним и тем же дистрибутивом одной и той же версии, аналогичные бинарники и либы, как правило, побитово совпадают. А вот конфиги - отнюдь.
> Может стоит подумать прежде чем говорить такие умные слова, как "централизация"?
Может, вам все-таки стоит почетче формулировать свои мысли?
> Я вам больше скажу: на самом деле, у всех компов с одним
> и тем же дистрибутивом одной и той же версии, аналогичные бинарники
> и либы, как правило, побитово совпадают. А вот конфиги - отнюдь.Я вам вот что скажу, бывают альтернативные пакеты, которые друг с другом конфликтуют, потому что один и тот же файл в разных пакетах скомпилирован с разными опциями.
Ваше решение приведёт к тому, что на двух разных серверах можно будет пользоваться только одним из альтернативных друг другу пакетов.
Ага, потом перенесут всё в /usr/ , поймет что приставка /usr не нужна, переименуют обратно в / и всё вернётся на круги своя.Читайте комментарий 1.3 http://www.opennet.me/openforum/vsluhforumID3/81122.html#3
Те, кто выступают за перенос, объясните мне, пожалуйста, в чём преимущество переноса следующих файлов (желательно по пунктам) из /sbin в /usr/bin:
1. httpd, udevd, proftpd, ...
2. fsck.*, mkfs.*
3. modprobe
4. init
5. useradd, usermod, userdelИ почему нельзя вместо переноса / в /usr сделать так, чтоб Федора могла грузиться с отмонтированным /usr?
Они везде пишут про selinux=0, видимо это им надоело :) С отказом от suid-битов защищаться будут сами приложения и конечно же selinux, это очевидно. Уже сейчас не надо задумыватся что init будет доступен всем и вся, достаточно прописать правило из audit2allow избавит от "надоедливых" сообщений и поставит всю систему под угрозу, но "who cares?"
Сама система устанавливается только один раз, корень представляет из себя все кроме /usr, /var, /opt, /boot, /home; как ранее говорили можно считать этот раздел read-only, весит он на порядок меньше чем /usr у рядового пользователя, а также в / меньше всего пишут, что в совокупности дает н-ный процент надежности. Более того в /usr сейчас лежат бинарники и библиотеки, которые нужны только в рабочей среде, но никак не предназначенные для экстренного случая восстановления системы. Те у кого накрывался (в простейшем случае вырубание питалова) хоть раз /usr меня поймут. А у тех у кого реал-тайм бэкапы вообще не парятся где и что лежит. Рядовым пользователям, на которых рассчитана федорка не нужно полагаться на бэкап системы, достаточно бэкапа данных. Но вы забываете, что запуск fsck намного лучше реинсталла всей системы, в предложенном варианте может спасти болванка/флешка с линуксом, а если ее нет под рукой?
> Более того в /usr сейчас лежат бинарники
> и библиотеки, которые нужны только в рабочей среде, но никак не
> предназначенные для экстренного случая восстановления системы.В современном виде, корень тоже слабо подходит для восстановления системы. Ни тебе testdiskа, ни photorecа.
> Но вы забываете, что запуск fsck намного лучше реинсталла всей системы
Запуск fsck с вываливаением кучи неидентифицированных файлов в lost+found тоже в конечном счете заканчивается реинсталлом системы. В сабже всего лишь предлагают свести к нулю вероятность софтового разрушения ФС корня.
Что это за "софтовое разрушение ФС корня" ? rm -rf / ? В большинстве случаев рушатся пластины, слетает головка в диске, а софтовые разрушения создают пользователи, в том числе и не приглашенные. О чем вы говорите?
> Что это за "софтовое разрушение ФС корня" ? rm -rf / ?Да. Или некорректное отмонтирование.
> В современном виде, корень тоже слабо подходит для восстановления системы. Ни тебе testdiskа, ни photorecа.photorec-ом вряд-ли можно загрузку починить. А testdisk вообще для поиска разделов предназначен. В случае, когда он нужен (пропала таблица разделов), скорее всего и до initrd не дойдет...
А parted, mdadm и fsck.* вполне себе на /sbin лежат.
>> photorec-ом вряд-ли можно загрузку починить.
> Да ну? Тогда то же самое можно сказать и про fsck. И
> то, и другое - инструменты для восстановления данных, только fsck помогает
> лишь при мелких проблемах, а photorec работает в более тяжелых случаях.Вы различаете случаи "система не грузится" и "нужно восстановить фотографии"?
/bin и /sbin предназначены только для того, чтобы починить негрузящуюся систему, а она может загрузиться и без фотографий.
У меня на сервере было 3 маленьких корневых раздела: 1 рабочий, и 2 по очереди получали копию рабочего перед обновлением. Сильно помогло 2 раза: первый - когда при обновлении выбило свет и UPS не выдержал; второй - когда опять же при обновлении навернулся rpm. И еще несколько раз сыграло роль backup-а для тер вещей, которые не додумался backup-ить нормально. Со здоровенным /usr это проблематично. А постоянно использовать initrd при загрузке с обычного носителя - излишняя сущность и ещё одна вешь, которая может сломаться. Но держать initrd на всякий пожарный - не помешает.
ой мама. в том же треде возникает поляк с предложением заменить #!/bin/sh на #!/usr/bin/env shмне одному это напоминает анекдот про кота, который лижет яйца потому, что может? все остальные проблемы в Редхате Петтеринг уже порешал?
> ой мама. в том же треде возникает поляк с предложением заменить #!/bin/sh
> на #!/usr/bin/env shO_O
/me ушёл, крестясь
> мне одному это напоминает анекдот про кота, который лижет яйца потому, что
> может?Нет, не только. У меня вообще ощущение, что редхатовские разработчики уже не знают чем пропиариться, то названия сетевых интерфейсов менять надумали, то вот теперь /usr им мешает...
> Нет, не только. У меня вообще ощущение, что редхатовские разработчики уже не
> знают чем пропиариться, то названия сетевых интерфейсов менять надумали, то вот
> теперь /usr им мешает...Ничего страшного. Через полгода будут плеваться, но сделают так во всех дистрах. Лёнчик Потный гениален. Жалко, что его шедевры мало кто оценил.
...практически дословно про кота и про проблемы. походу в команде появились эффективные менеджеры. ждём массовых переименований, переносов с места на место и других офигенно полезных вещей.
Интересно, чем это закончится?
нифига се понаписали)))... сугубо мое мнение что для десктопного дистра можно все в одну папку запихнуть... ничего страшного не произойдет... про отцов и дедов улыбнуло))))... я лично за прогресс! пусть меняют пусть делают пусть пробуют!!!ЗЫ дистров все равно много и каждый надет что то и для себя... не огарчивайтесь
> папку
> ничего страшного
> за прогресс!Видите ли, одна из бед общества -- это когда им начинают руководить юнцы, не набившие ещё должного количества шишек и не понимающие существенной части последствий своих дел.
В *NIX нету "папок" на уровне фундамента системы.
Если ломать стройную и работающую концепцию из-за нежелания исправить свой ляп, страшное может и произойти.
Прогресс -- отнюдь не самоценность, а нередко вообще шаблонный жупел ("он против прогресса! он против демократии! да он вообще антисемит!").
> ЗЫ дистров все равно много
Из того, что людей много, не следует то, что изуродовать хотя бы одного -- это мелочи.
PS: (страшное подозрение) слушайте, а может, это признак не освоившего кнопку <tab>?
>> папку
>> ничего страшного
>> за прогресс!
> Видите ли, одна из бед общества -- это когда им начинают руководить
> юнцы, не набившие ещё должного количества шишек и не понимающие существенной
> части последствий своих дел.Видите ли, Майкл, проблема сообществ заключается в том, что это анархия, а не автократия или меритократия, как пытаются ее представить некоторые юнцы. Юнца от пролезания на верхушку сообществ никто не удержит. Не существует таких механизмов в СПО, увы. Отсюда бардак и анархия, которая так по нраву многим деятелям и которую ошибочно считают синонимом слова "свобода".
> В *NIX нету "папок" на уровне фундамента системы.
> Если ломать стройную и работающую концепцию из-за нежелания исправить свой ляп, страшное
> может и произойти.
> Прогресс -- отнюдь не самоценность, а нередко вообще шаблонный жупел ("он против
> прогресса! он против демократии! да он вообще антисемит!").Практически в Линукс - сообществе с его ярко выраженной религиозной окраской - повсеместно.
>> ЗЫ дистров все равно много
> Из того, что людей много, не следует то, что изуродовать хотя бы
> одного -- это мелочи.А дистроватч это разве не коллекция фриков? (невинно) Изуродованных прямо по Гюго гуинпленов?
>что это анархияЯ бы не сказал. Решения принимаются централизованно и порой одним человеком. То что мы видим сейчас, это не предложение, а декларация намерений. То что "предлагает" Леннарт практически всегда внедряется без вопросов. Даже глючное, даже недоделанное. Короче, в основной пачке дистрибутивов это будет 100%. Останутся какие-нибудь аутсайдеры вроде slackware. Только и всего.
> То что "предлагает" ЛеннартБеда только в том, что Леннарт достаточно последователен в предложениях:
e) the split between sbin/ and /bin is effectively made redundant already,
since both are listed in the $PATH of all users already since a
couple of Fedora versions.
>the split between sbin/ and /bin is effectively made redundant already,since both are listed in the $PATH of all users already since a
couple of Fedora versions.
Убойный аргумент, что тут сказать. Специально вот создал юзера и убедился, что даже в мандриве не так.
[user@localhost ~]$ export | grep "declare -x PATH"
declare -x PATH="/usr/share/colorgcc:/usr/bin:/bin:/usr/local/bin:/usr/X11R6/bin/:/usr/games:/usr/lib/qt4/bin:/home/user/bin"
> Убойный аргумент, что тут сказать.Это самое только малое.
Заморочился пройтись по треду. Уж очень любопытно стало.
Кратко:> I can help with it. I only need to know how to find all scripts that
> uses #!/bin/sh without installing all packages :)A reasonable approximation is "repoquery --whatrequires /bin/sh". I
count 5319 packages -- good luck...Следом:
Cool idea. Next I suggest to stop using
/bin
/sbin
/lib
/lib64
in F19, and not to create these links on freshly installed systems in F20.А вот это хороший вопрос:
What do they get if they boot single user and /usr
is on an nfs filesystem?К тому же FHS в fedora отправляется в разлом.
Ну и напочитать:https://lists.fedoraproject.org/pipermail/devel/2011-October... и далее по треду
https://fedoraproject.org/wiki/Features/UsrMove
http://pathname.com/fhs/pub/fhs-2.3.html
>> Убойный аргумент, что тут сказать.
> Это самое только малое.
> Заморочился пройтись по треду. Уж очень любопытно стало.
> Кратко:
>> I can help with it. I only need to know how to find all scripts that
>> uses #!/bin/sh without installing all packages :)
> A reasonable approximation is "repoquery --whatrequires /bin/sh". I
> count 5319 packages -- good luck...
> Следом:
> Cool idea. <...>М-дэ. POSIX не для них, да. Ну да, да, нет других *nix кроме Linux, нет другого Linux кроме Fedora, нет другого члена сообщества Fedora, кроме Леннарта...
> Беда только в том, что Леннарт достаточно последователен в предложениях:Отнюдь.
> e) the split between sbin/ and /bin is effectively made redundant already,
> since both are listed in the $PATH of all users already since a
> couple of Fedora versions.Ну и болваны, опять же. Зачем пользователю fsck? (я знаю, но такой пользователь тоже знает)
А вред вроде бы очевиден любому немышевозу -- уничтожение неймспейсов приводит к захламлению и усложнению работы табом.
> Видите ли, Майкл, проблема сообществ заключается в том, что это анархияЩаз.
> (невинно)
Да-да, установите обновлённые драйвера дешёвого троллинга, MSKBнепомню. Этот уже ловится.
мдааа... ну ты же меня понял что я имеел ввиду... пусть будет не папка а директория бог с ним...
ЗЫ. и кстате человек сидяший на альте наверна должен так себя вести)) как гуру))) как все знающий и все понимающий!!)))
> мдааа... ну ты же меня понял что я имеел ввиду... пусть будет
> не папка а директория бог с ним...Дядьку, да я-то понял, просто когда человек оперирует точными терминами и грамотно излагает мысли, то с ним намного проще иметь дело. В технической документации слово "folder" не припоминаю, в отличие от слова "directory". Вопрос не столько терминологический, впрочем, сколько культурный -- на винде и маке принято кидать без разбору, там в ходу фолдеры; на юникс-подобных системах принято содержать в порядке и данные, и систему -- тут в ходу каталоги/директории. В чём-то перекликается с посетителем библиотеки и библиотекарем: одному "да какая разница", второму она видна.
> ЗЫ. и кстате человек сидяший на альте наверна должен так себя вести))
> как гуру))) как все знающий и все понимающий!!)))Боюсь, если бы сидел на дебиане или арче, эта проблема бы осталась... Просто отдельный /usr и/или маленький (300M..1G) корень меня не раз выручал, поэтому мне есть что сказать и на эту тему.
А сказать вот что хотел:
1) в UNIX разработана и проверена практикой схема системных каталогов, имеющая много достоинств (в т.ч. в "редких" случаях и прочих нештатных ситуациях);
2) люди опытные понимают, что друг познаётся в беде, а система -- в аварийном состоянии;
3) люди неопытные нередко отличаются тем, что не видят разницы (существующей).Так вот когда в редхате всерьёз поднимается вопрос о том, чтобы в принципе упразднить /usr как возможность -- возникает вопрос в профпригодности по этим трём пунктам.
Потому что отдельный /usr полезен как минимум:
a) при нештатных ситуациях (шанс повреждения большой ФС всегда больше при прочих равных);
b) для бездисковых станций (сейчас не всегда осмысленно делать тонких клиентов, но обслуживать десятки почти одинаковых машин индивидуально -- всё так же глупо и дорого).Да, сейчас он менее актуален, чем десяток лет тому. Но "выгода", которую пытаются впарить -- это маскировка бага под названием "макаронный дизайн", когда существенно различные части системы слишком много знают о потрохах друг друга и слишком на них завязаны. Платить же за одёжку для уродства этими полутора процентами случаев, когда "ненужное" берёт и выручает -- продолжает видеться глупым.
Понимаете, я вот сейчас сижу и лопачу наслоения такого спагетти в mkimage-profiles-desktop, а некоторые и в делаемом mkimage-profiles остаются (размеченные # FIXME). Оно просто раньше или позже выходит боком, любой программист со стажем подтвердит.
> 1) в UNIX разработана и проверена практикой схема системных каталогов, имеющая много достоинств (в т.ч. в "редких" случаях и прочих нештатных ситуациях);Это верно, однако, думаю, стоит вспомнить предпосылки, которые привели к существующей иерархии файловой системы... Когда-то давным-давно, когда деревья были выше, трава зеленее, а компьютеры "больше", операционная система UNIX распространялась на стримерных лентах и её установка была, в общем, нетривиальна. При этом, дисковая память (да и оперативная, но не о ней речь) была дорогая/дефицитная. Поэтому и использовалась "хитрая" схема с локальным корнем и /usr, смонтированным по NFS. Такая схема позволяла восстановить работоспособность сети (ибо в корне, да ещё и ro, ломаться, в общем, нечему, а проблемы с оборудованием из другой оперы), чтобы смонтировать /usr. Ну и дополнительно упрощалось обслуживание/сопровождение парка компьютеров за счёт единственной для каждой архитектуры копии /usr.
> a) при нештатных ситуациях (шанс повреждения большой ФС всегда больше при прочих равных);В современном мире, по большому счёту, нет нужды любой ценой сохранять работоспособный корень, потому что больше не нужно загружать/устанавливать ОС со стриммерных лент. Ведь можно легко и непринуждённо загрузиться с Recovery CD/DVD/USB или даже из сети и починить всё, включая корень и сеть.
> b) для бездисковых станций (сейчас не всегда осмысленно делать тонких клиентов, но обслуживать десятки почти одинаковых машин индивидуально -- всё так же глупо и дорого).
Тоже спорный вопрос. В современном мире существуют умные пакетные менеждеры, учитывающие множество факторов при установке пакетов, обёртки к этим пакетным менеджерам типа apt/yum/zypper/т.п., значительно облегчающие управление пакетами и ПО типа puppet, позволяющее управлять значительным количеством компьютеров с незначительными трудозатратами. А! Да! И дисковая память теперь дёшева. Соответсвенно, можно достаточно просто и успешно "обслуживать десятки почти одинаковых машин" но не "индивидуально", а "скопом".
Ну и, опять же, в некоторых случаях проще установить ОС заново, чем лечить поломанную (но это больше относится к Windows) - чай не со стримером мучиться.
по мне UNIX схема достаточно деревянная... и на нее я ссылатся вообще не хочу... есть просто вещи которые необходимо модернизировать... я тоже не первый раз подрова хожу и по своему опыту могу сказать что мне на десктопе будет удобней что все исполняемые фалы будут лежать в одном месте))ЗЫ. будь проще друг и к тебе потянутся)))
> по мне UNIX схема достаточно деревянная...
> ...
> на десктопе будет удобней что все исполняемые фалы будут лежать
> в одном месте))А потом в довесок каспера прикрутить.
Первая атака на iniramfs для отказа монтирования /usr и на первой перезагрузке ваша система в ауте. Модули ядра тоже. И bash прицепом туда же.$ find /bin/ -name mount
/bin/mount# find /lib/ -name modules
/lib/modulesУгу?
И тоже десктоп. Чем же FHS не угодила? Нет проблем? Скучно жить?
я тебя честно не очень понял... но поживем увидим
> я тебя честно не очень понял...Там очевидно. Если монтирование /usr, а оно будет идти из inird, сломается (или кто-то "сломает"), в аут уйдут kernel-modules которые будут лежать в несмонтированном /usr/lib, ну и bash туда же следом. Т.е. остаёмся и без ядерных модулей и без консоли. Графика в ауте как необсуждаемое.
Таким образом Леннарт /usr гайками к корню прикрутил и резьбу заварил, чтобы не откручивали. А это Виндовс-way. Отрывать /usr от корня при таком раскладе нельзя.
К тому же в некоторых дистрибутивах ради спокойной жизни /sbin, /usr/sbin принципиально оторвано из PATH даже у root, предполагая, что если лезет, то знает зачем. Леннарт же эти каталоги уже втиснул пользователю в PATH, что глупость несусветная, даже в глазах малоискушенного пользователя. Переводя на шутку: граната в определённых случаях штука полезная, но дают её не всем. Да и прячут её подальше не таская по прешпекту. Во избежание.
Пока пользователю терпеливо внедряли что всё держать в корне нехорошо и вроде бы приучили, мавр сделал своё дело.
а понял ты забезопасность кичишся... но видимо ленарт на селинукс оч расчитывает... а виндовс ваем тут и не пахнет по мойму и есть ли тако вообще)))... хотя безопасности ради возможно sbin лучше и сотавить
Есть такая народная мудрость: "семь раз отмерь - один отрежь". Намного дальновиднее сначала подумать о последствиях, а уж затем делать. Но для некоторых (вас к ним, похоже, тоже можно отнести) главное - действие, остальное второстепенно.
Существуют дистрибутивы, которые не могут загрузиться без initramfs и смонтированного до запуска /sbin/init /usr?
ППЦ. Они сами себе злобные буратины. Скоро, как гугль, для делания хоть чего-нибудь начнут требовать наличия подключения к интернету.
Похоже разработчики федоры работают по принципу:
Ломай - чини @ без дела не сиди.
> Разработчики дистрибутива Fedora Linux рассматривают (http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/1...)
> возможность перемещения всех имеющихся в системе исполняемых файлов в одну директорию.
> Иными словами, предлагается (https://fedoraproject.org/wiki/Features/UsrMove) размещать
> исполняемые файлы только в каталоге /usr/bin, а директории /bin, /sbin и
> /usr/sbin преобразовать в смволические ссылки, указывающие на /usr/bin. По аналогии предлагается
> упразднить /lib и помещать все системные библиотеки только в директории /usr/lib.Вот здесь - http://freedesktop.org/wiki/Software/systemd/separate-usr-is... - кстати, говорится немного другое: "We hope to move all tools that have been moved to / over time, back to /usr where they belong, and the rootfs will only contain compat-symlinks into /usr." То есть вынести к чертям всю ту помойку (ALSA, dbus, networkmanager...), что позапихивали в /, на положенное ей место в /usr, а симлинки оставить для совместимости с программами, рассчитывающими на старое местоположение. ИМХО, симлинки в общем случае будут излишком (программы надо исправлять, а не каталоги симлинками захламлять), но общий курс как раз выглядит верным...
> Также упоминается то, что объединение sbin и bin вызовет необходимость действий со стороны разработчиков upstream-проектов.
> Файлы и каталоги, присутствие которых необходимо вне иерархии /usr предлагается связывать при помощи символических ссылок.И какие такие действия необходимы со стороны разработчиков upstream-проектов?
>И какие такие действия необходимы со стороны разработчиков upstream-проектов?Очевидно, выпиливать отовсюду */sbin По лёгкому взмаху руки одного программного импотента.
> столько кирпичей, а из-за чего собственно? хорошее начинаниеЕсли это начинание по выносу мусора из / в /usr, как написано на FreeDesktop.org, то это хорошо.
Если же это начинание по сливанию всего в одну кучу, как это звучит в тексте новости, то с таким хорошим начинанием плохих не надо.
> Разработчик сказал "я делаю А", некий лох на сайте разместил новость "разработчик
> делает Б". Кому верить? Я, как и вы, в полном неудоумении...Лох не лох, но вброс в любом случае вышел знатный. :)))
> Разработчик сказал "я делаю А", некий лох на сайте разместил новость "разработчик
> делает Б". Кому верить? Я, как и вы, в полном неудоумении...В новости как раз всё верно сказано, в Fedora именно всё в кучу хотят свялить. У них в плане даже картинка есть:
/
|-- etc
|-- usr
| |-- bin
| |-- lib
| `-- lib64
|-- run
|-- var
|-- bin -> usr/bin
|-- sbin -> usr/bin
|-- lib -> usr/lib
`-- lib64 -> usr/lib64обратите внимание, что ссылка /sbin ведёт на /usr/bin, и в /usr больше нед /usr/sbin это и есть сваливание в кучу.
Вот эта идея именно то, что и называют "от глюкавого!"...У меня даже нет слов! Бред, полнейший. С таки же успехом можно DNS обратно превращать в "плоскую" систему имен.
Иерархия нужна однозначно. Уж хотя бы для безопасности. Потом есть еще такая вещь как скорость обработки запросов - иерархичные системы почему то куда быстрее в поисковых запросах. А раздельные каталоги преследует именно эту цель: не класть яйца в одну корзину.
То что эта идея полный п...ц, я заявляю именно как линуксовый сисадмин. Сертифицированный, кста (если кому это интересно).
В принципе этот дистрибутив не относится к классу стандартов, это так называемый development tools и таким останется - так что делать можно все что хочется
>В принципе этот дистрибутив не относится к классу стандартов, это так называемый development tools и таким останется - так что делать можно все что хочетсяНе забывай про /run Где он первым появился? А уж про такие вещи как systemd, pulseaudio, netrworkmanager я скромно промолчу.
> В настоящее время дистрибутив нереально загрузить без /usr
> (/usr монтируется из initramfs до запуска процесса инициализации и
> содержит необходимые для загрузки компоненты)Если и в самом деле додумались до этой глупости (все-таки думаю, что это гипербола),
то ее и надо чинить, вместо того, чтобы учудить еще одну.Умиляет довод, что /usr можно будет монтировать на разных машинах.
Это как раз сейчас и можно, поскольку и без /usr система работоспособна и может
обеспечить такое монтирование (или они из initramfs хотят /usr монтировать, делая машину
полностью неработоспособной при сбое сети).
> а также то, что в sbin можно найти программы, которыми пользуются и обычные пользователи.Вот в дэбиане вызывать ifconfig можно только с указанием пути: /sbin/ifconfig. Ничего поменять нельзя, но отобразить же и обычный пользователь имеет право.
Вот это инновация!
А почему бы вообще все файлы не скидать в одну папку?
Ууу, какие перспективы открываются...
Зачем вообще тогда эта стандартная структура папок создавалась?