The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"В Fedora рассматривается предложение по переносу всех исполн..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от opennews (ok) on 01-Ноя-11, 21:16 
Разработчики дистрибутива 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...
Новость: https://www.opennet.ru/opennews/art.shtml?num=32194

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "В Fedora рассматривается предложение по переносу всех исполн..."  +19 +/
Сообщение от tonys email(ok) on 01-Ноя-11, 21:16 
c:\program files
:-)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от umbr (ok) on 01-Ноя-11, 21:46 
Да, осталось только переименовать /usr/bin в /Program_Files
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

20. "В Fedora рассматривается предложение по переносу всех исполн..."  +7 +/
Сообщение от Аноним (??) on 01-Ноя-11, 21:59 
Для этого /opt есть...
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

86. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от tmx on 02-Ноя-11, 00:37 
>Да, осталось только переименовать /usr/bin в /Program_Files

тогда уже в /Program Files

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

265. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от ананим on 02-Ноя-11, 22:50 
>Да, осталось только переименовать /usr/bin в /Program_Files

а куда девать windows\\system32 ?

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

19. "В Fedora рассматривается предложение по переносу всех исполн..."  +7 +/
Сообщение от Шнупс on 01-Ноя-11, 21:59 
Смешно, но в винде там всё что можно лежит, а тут будут только бинарники
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

65. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от Викрам on 01-Ноя-11, 23:54 
program files/bin ?
program files/lib ?
program files/share ?
не гоните, сударь.

а вот opt - это и есть аналог програм файлс

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

166. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от openclocker (ok) on 02-Ноя-11, 09:18 
В Windows как раз таки идет разделение, системные программы лежат в C:\Windows\, а пользовательские в C:\Program Files\, а также в тех папках (которые указывает сам пользователь).
P.S. По крайней мере, так было в Windows XP.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

219. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 16:14 
> В Windows как раз таки идет разделение, системные программы лежат в C:\Windows\,
> а пользовательские в C:\Program Files\

Только что-то сразу после инсталла в C:\Program Files\ полно всякого хлама :)

Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

222. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 02-Ноя-11, 16:22 
> В Windows как раз таки идет разделение, системные программы лежат в C:\Windows\,
> а пользовательские в C:\Program Files\, а также в тех папках (которые
> указывает сам пользователь).
> P.S. По крайней мере, так было в Windows XP.

В "Program Files" кладётся банально то, что легко отделить от системы. Это по-прежнему часть винды. Проще говоря, там лежит то, что разработчикам винды показалось удобнее и/или логичнее положить туда, и всё.

Хорошее разделение в Windows есть в другой области: Local Settings в пользовательском профиле. Казалось бы мелочь, но при грамотном использовании повышает скорость работы с сетевыми профилями (в AD). FreeDesktop.org двинулись в этом направлении, сделав ~/.local, но в никсах это смотрится несколько убого. Логичнее было бы /var/tmp с квотами, но и этот вариант не без подводных камней...

Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

242. "В Fedora рассматривается предложение по переносу всех исполн..."  +4 +/
Сообщение от Ваня on 02-Ноя-11, 17:42 
Увы, в 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".

Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

243. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 02-Ноя-11, 18:00 
> Увы, в 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 в каких-то редакциях позволяет задавать диск для размещения папки профилей, но могу и путать...

Ответить | Правка | ^ к родителю #242 | Наверх | Cообщить модератору

250. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 19:51 
Каталог пользователя в Windows XP можно перенести в любое другое место - вроде бы открыть свойства каталога и задать новый путь при помощи волшебной кнопки, и он тут же будет перемещен. Уже не помню деталей, но я это делал разок. Но это конечно не оправдывает кучу хлама в documents and settings. Название, кстати, бестолковое - такое ощущение, что им чуть-чуть не хватило до варианта "Документы и всякая хня"
Ответить | Правка | ^ к родителю #243 | Наверх | Cообщить модератору

252. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 02-Ноя-11, 19:55 
> Каталог пользователя в Windows XP можно перенести в любое другое место -
> вроде бы открыть свойства каталога и задать новый путь при помощи
> волшебной кнопки, и он тут же будет перемещен.

Это вы про папку "Мои документы". Она лишь часть профиля.

> Уже не помню
> деталей, но я это делал разок. Но это конечно не оправдывает
> кучу хлама в documents and settings. Название, кстати, бестолковое - такое
> ощущение, что им чуть-чуть не хватило до варианта "Документы и всякая
> хня"

В Win7 это теперь Users.

Ответить | Правка | ^ к родителю #250 | Наверх | Cообщить модератору

2. "В Fedora рассматривается предложение по переносу всех исполн..."  –5 +/
Сообщение от Аноним (??) on 01-Ноя-11, 21:19 
В ориентированных на среднячков дистрах делайте что хотите. Только, прошу, не трогайте дистры ориентированные на профессиональное использование. Разделеннние нужно. Возможно оно не особо нужно в какой-нибудь убунте ...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от Yet Another Anonimous on 01-Ноя-11, 21:37 
ну ка, продемонстрируй свое мнение, зачем же нужно разбиение?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

80. "В Fedora рассматривается предложение по переносу всех исполн..."  +14 +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:27 
> ну ка, продемонстрируй свое мнение, зачем же нужно разбиение?

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

118. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:45 
> знать не хотим никаких прогрессов.

А давайте в / сразу все вывалим, как в CP/M. И объявим это прогрессом :). Ведь история развивается по спирали.

Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

187. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 12:49 
> Иерархия должна быть стройной и логичной, иначе она теряет смысл.

Тогда уж почему /usr/bin? А не просто /bin? И пачка симлинков - все еще больше запутает и сглючит, пожалуй.

Ответить | Правка | ^ к родителю #243 | Наверх | Cообщить модератору

193. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Гость on 02-Ноя-11, 13:12 
>> Иерархия должна быть стройной и логичной, иначе она теряет смысл.
> Тогда уж почему /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        

Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

195. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от dxd on 02-Ноя-11, 13:36 
Haiku?
Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

198. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 13:44 
почти угадал :)
Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

251. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от Аноним (??) on 02-Ноя-11, 19:55 
Наличие прописных букв в начале слов подсказывает, что их мало кто набирал руками
Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

284. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Гость on 03-Ноя-11, 12:12 
Не аргумент - макинтошников большие буквы не останавливают ;) Кстати, откуда иерерхия? На редкость логичное построение в плане распределения по дискам для современных условий.
Ответить | Правка | ^ к родителю #251 | Наверх | Cообщить модератору

81. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:33 
Чтобы шаловливые ручки пользователей не запускали прог из /sbin и не жаловались на отсутствие прав рута
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

105. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:22 
> Чтобы шаловливые ручки пользователей не запускали прог из /sbin и не жаловались
> на отсутствие прав рута

Трепотня это все.
Если пользователь догадался, как открыть консоль и ввести там команду ifconfig, то нагуглить приписку /sbin его пытливому уму явно не проблема.

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

129. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 02:27 
>Трепотня это все.
>Если пользователь догадался, как открыть консоль и ввести там команду ifconfig, то
>нагуглить приписку /sbin его пытливому уму явно не проблема.

Да? Знаете ли, группа обычных юзверей не видит содержимое sbin. Нет надобности.

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

128. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 02:25 
>ну ка, продемонстрируй свое мнение, зачем же нужно разбиение?

Группа обычных пользователей не просматривает sbin. Риоднли запуск реально нужен? А в "убунтах" (пользовательская убунта на пользовательском ноуте) хоть всю /usr/*bin вываливайте в ~/.local/bin .

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

148. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 04:07 
> Группа обычных пользователей не просматривает sbin.

И что это дает? Можно убирать проверки на рутовые права и ставить suid root для находящихся там программ?

> Риоднли запуск реально нужен?

Да. Некоторым.

Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

151. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 05:52 
>>Группа обычных пользователей не просматривает sbin.
>И что это дает? Можно убирать проверки на рутовые права и ставить suid root для
>находящихся там программ?

Разделение не дает смешения системых утилит. Запрет на их запуск дает мне спокойствие на случай обнаружения багов в системых утилитах. Чем больше утилит - тем больше вероятность нахождения багов среди утилит. Тот же эффект от недоступности информации о системых утилитах. Согласен что не панацея, но наличие оного лучше чем его отстутсвие, не так ли? Поэтому я пишу о значимости разделения в зависимости от областей использования дистрибутива (словосочетание "профессиональный подход" как бы намекает на это).

Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

158. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от ach (ok) on 02-Ноя-11, 08:39 
>>ну ка, продемонстрируй свое мнение, зачем же нужно разбиение?
> Группа обычных пользователей не просматривает sbin. Риоднли запуск реально нужен? А в
> "убунтах" (пользовательская убунта на пользовательском ноуте) хоть всю /usr/*bin вываливайте
> в ~/.local/bin .

Что значит "не просматривает"? В PATH нет? На том же RH или Fedora ifconfig от пользователя прекрасно запускается через /sbin/ifconfig.

Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

178. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Moomintroll (ok) on 02-Ноя-11, 11:30 
В openSUSE (видимо и в SLES) нужно писать /sbin/ifconfig
Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

259. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от Michael Shigorin email(ok) on 02-Ноя-11, 22:11 
> ну ка, продемонстрируй свое мнение, зачем же нужно разбиение?

Если мнение не сложилось, можно почитать
http://tldp.org/HOWTO/Partition/index.html
http://tldp.org/HOWTO/Multi-Disk-HOWTO.html
(упреждающий ответ тем, кто попытается не читая поржать над датами: а вы почитайте, ещё спасибо скажете, даже если виндузятники)

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

12. "В Fedora рассматривается предложение по переносу всех исполн..."  +13 +/
Сообщение от Avatar (??) on 01-Ноя-11, 21:38 
Главное чтобы слово ПРОФЕССИОНАЛ в зубах не застревало.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

24. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Vladjmir email(ok) on 01-Ноя-11, 22:11 
За Федорой поятнутся все остальные. А потом и в LSB это зафиксируют.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

26. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от sir_sigurd on 01-Ноя-11, 22:15 
лолчто?
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

29. "В Fedora рассматривается предложение по переносу всех исполн..."  +3 +/
Сообщение от Vladjmir email(ok) on 01-Ноя-11, 22:23 
За Федорой потянутся все остальные, по крайней мере rpm-based дистрибутивы, чтобы не нарушать совместимость и чтобы можно было без большого гемора копиластить оттуда пакеты. В deb-мире всё сложнее. Космонавт тоже вроде не против, но он зависит от дебиана и, думаю, не будет радикально ломать с ним совместимость и увеличивать себе объём работы.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

119. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от fork (??) on 02-Ноя-11, 01:45 
За Федориным горем ?
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

153. "В Fedora рассматривается предложение по переносу всех исполн..."  +3 +/
Сообщение от www2 (??) on 02-Ноя-11, 07:57 
Да, федорино горе - это общее горе. Из него все нововведения со временем попадают в остальные дистрибутивы. Те же PulseAudio и systemd. Так что и Debian тоже примет эти изменения, не сомневайтесь. Примеры уже имеются - перенос правил udev из каталога /etc/udev/rules.d/ в каталог /lib/udev/rules.d/, а в /etc/udev/rules.d/ остались только изменённые или настроенные вручную правила.
Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

218. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от zomg on 02-Ноя-11, 16:11 
Это все правда. /run уже в арче.
Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

82. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:34 
> За Федорой поятнутся все остальные. А потом и в LSB это зафиксируют.

Ну главное - чтобы не в FHS

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

152. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 06:15 
>Смотря в какой области. Вот, например, для профессионалов в IT тут ничего страшного нет - просто избавление от бессмысленного ритуала и добавление новых возможностей.

А вот для профессионалов в области рассуждения о том, как правильно жить - действительно, довольно вредное и опасное нововведение.

Что-то личное? Я вижу смысл в разделении на "важных" системах. Вы, по-видимому, нет. Еще вопросы?

>> Разделеннние нужно.
>Правильно, а аргументы - не нужны.

Читайте ветку - там есть мои ответы на вопрос почему у меня такая позиция. Остается только вопрос согласия с моей позицией. Но это и другой вопрос и малозначимый, так как каждый волен по-своему настраивать свое окружение.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

266. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 23:02 
Не потянуться, лично меня вполне устраивает свой старенький дистр ASPLInux Cobalt 14. И корневые разделы тоже. А что касается, что "все пользователи потянуться за Fedora" так это вряд ли. Fedora 15 еще не устранила баги в своем дистре, а уже клепает Fedora-17. На мой взгляд, лучше бы доделали то, что есть, а уже потом клепали бы себе Fedora 17.

P.S. Лично меня не волнуют дистрибутивы, которые в свою очередь используют "облачные технолонии" (наподобие Мандривы 2011), мне, как пользователю важно то, чтоб была возможность настроить все приложения, папки, игры и редакторы по своему усмотрению. А вот менять уже сложивжуюся корневую систему, смысла не вижу.  

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

3. "В Fedora рассматривается предложение по переносу всех исполн..."  +28 +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Ноя-11, 21:26 
М-дэ. Раз уж сломали независимость от /usr, то следующий шаг, конечно, логичен. Но чем-то мне это напоминает старую байку (которая вроде как и не байка) времён застоя:

На карандашной фабрике было внесено рацпредложение: ведь никто не стачивает карандаш до конца - так зачем графит класть по всему стержню? Можно сэкономить несколько сантиметров более дорогого материала. Рацпредложение было принято в производство.

Через эн месяцев на другом совещании было внесено ещё одно рацпредложение: у нас в карандашах есть часть, которой никто никогда не сможет рисовать, потому что в ней нет графита - так давайте её уберём и сэкономим несколько сантиметров дерева! Рацпредложение тоже было принято в производство...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

290. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от kibab on 03-Ноя-11, 17:53 
Ну так это типичный ход развития событий в Linux. Вместо того чтобы чинить обратно независимость от /usr, давайте сделаем помойку и не будем больше вспоминать о том, зачем, собственно, было сделано разделение.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "В Fedora рассматривается предложение по переносу всех исполн..."  –2 +/
Сообщение от Avatar (??) on 01-Ноя-11, 21:29 
Ну хоть бы что-то с этим колхозом директорий сделали!

А вообще мне нравится структура как в http://gobolinux.org. Но пока до этого дойдут...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от anonymus on 01-Ноя-11, 22:17 
> Ну хоть бы что-то с этим колхозом директорий сделали!
> А вообще мне нравится структура как в http://gobolinux.org. Но пока до этого
> дойдут...

там это сделано ужастнейшим костылем. нет, пусть уж лучше остается как есть пока не придумают что-нибудь лучше

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

232. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 16:57 
Неважно как это реализовано, важно то, что идея хорошая (правильная). Мне понравилось.
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

28. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Vladjmir email(ok) on 01-Ноя-11, 22:18 
Структура каталогов сложилась в Линуксе исторически. Видимо, редхатовцы не хотят ломать её радикально, как GoboLinux, но хотят упростить и сделать нечто подобное GoboLinux (а точнее подобное винде, т.к. Gobo взял аналог структуры папок из винды).
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

37. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 01-Ноя-11, 22:50 
> Ну хоть бы что-то с этим колхозом директорий сделали!

Угу, фермерское хозяйство девяностых.

> А вообще мне нравится структура как в http://gobolinux.org.
> Но пока до этого дойдут...

А мне не нравится, вплоть до причисления додумавшихся к латентным виндузятникам.  Хотя, возможно, до них когда-то действительно дойдёт.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

160. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от ach (ok) on 02-Ноя-11, 08:41 
>> Ну хоть бы что-то с этим колхозом директорий сделали!
> Угу, фермерское хозяйство девяностых.
>> А вообще мне нравится структура как в http://gobolinux.org.
>> Но пока до этого дойдут...
> А мне не нравится, вплоть до причисления додумавшихся к латентным виндузятникам.  
> Хотя, возможно, до них когда-то действительно дойдёт.

+1. Подобные идеи могут выдвигать только те, кто не понимает зачем так было задумано.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

213. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Гость on 02-Ноя-11, 15:27 
Этого "зачем" уже много лет нигде кроме эмбеддед не видели, не надо ляля
Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

294. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Анонимкус email on 04-Ноя-11, 00:46 
А мне нравится, ну почти. По крайней мере идея нормальная. Длинный имена каталогов с большой буквы это конечно явный баг :).

Не вижу чем переход к такой структуре помешает разделить пользовательское и системное ПО, только легче станет. Для восстановления системы гораздо лучше IMHO использовать рам-диск. Разделение доступа, опять же по-моему скромному мнению, лучше поручить системам а-ля AppArmor и другим подобного типа определяющим правила доступа по пути, кстати при переходе к подобной структуре правила должны стать заметно проще, ведь достаточно описать права одной директории и наследовать их для всех дочерних объектов, нежели описывать права для каждого (важного) файла пакета.

И мейнтейнерам жить должно стать легче (хотя Михаилу виднее), ведь по-сути стандарт не описывает (IMHO) досконально структуру ФС,  а соответственно расположение файлов программ различается от дистриба к дистрибу, причем иногда существенно. При этом соответственно каждый мейнтейнер взяв от мейнстрима исходники занимается составлением/переписыванием правил определяющих где и что должно лежать, т.е. строит/переделывает "велосипед" (в некотором смысле).

Внутри директории программы очевидно стоит оставить все как есть, т.е. обычное юникс-дерево.

Единственное, что меня напрягает, решение в виде триллиона ссылок (хотя сейчас из-за обратной совмстимости этого наверное не избежать). Вопрос с вызовом бинарников и т.д., мне кажется (по крайней мере относительно исполняемых файлов) это должно решаться на уровне ФС, в ней все равно храняться все биты доступа. Нужно просто сделать хранилища, кеши, со списком исполняемых файлов, суид и т.д. И внести изменения в системные вызовы типа exec, которые будут искать по кешу если вызов сделан по относительному пути. Обновление кеша может происходить как по-требованию, так и автоматически при chmod.
По сложности IMHO это не превысит текущего решения с симлинками, но будет красивее.

Кстати парочку симлинков при желании никто не мешает.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

44. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от AlexYeCu (ok) on 01-Ноя-11, 23:05 
Почитал на wiki.
Надеюсь, такого ужаса я никогда не увижу в приличных дистрибутивах.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

223. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 16:25 
> Почитал на wiki.
> Надеюсь, такого ужаса я никогда не увижу в приличных дистрибутивах.

/run уже портировали, ждите изменений в FHS.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

58. "В Fedora рассматривается предложение по переносу всех исполн..."  +3 +/
Сообщение от Ytch on 01-Ноя-11, 23:37 
> А вообще мне нравится структура как в 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/:.......

... и это только самое начало

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

141. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от xio on 02-Ноя-11, 03:45 
В лупе можно обойти, например.
Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

272. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Ytch on 03-Ноя-11, 02:00 
> В лупе можно обойти, например.

А как весело в скриптах-то!

#!/Programs/Bash/4.1/bash
...

Проапдейтил систему - вперед! Переписывай все скрипты! Праздник!

Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

171. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Gular (ok) on 02-Ноя-11, 10:33 
Можно сделать что-нибудь, чтобы подобный текст не растягивал верстку страницы?
Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

188. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 12:53 
> Можно сделать что-нибудь, чтобы подобный текст не растягивал верстку страницы?

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

Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

270. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Клыкастый (ok) on 03-Ноя-11, 00:39 
смотрите шире: можно что-нибудь сделать, чтобы никогда такого не увидеть?
Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

296. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Пр0х0жий (??) on 05-Ноя-11, 04:29 
> мне нравится структура как в 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  

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 01-Ноя-11, 21:31 
Интересно...

А /usr/local/bin тоже выпиливаем?

А как тогда разные версии юзать?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 01-Ноя-11, 21:36 
/opt/bin и /home/user/bin
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

32. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от Vladjmir email(ok) on 01-Ноя-11, 22:35 
> /home/user/bin

Не, не, не, только не это... Вы хотите превратить хомяк в свалку бинарников и библиотек, в то время как безопасность требует обратного (noexec на весь хомяк)?

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

49. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 01-Ноя-11, 23:22 
> noexec на весь хомяк

Фигня. Любой доступный юзеру файл он сможет запустить, скопировав его в /tmp и поставив права на исполнение

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

54. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от pavlinux (ok) on 01-Ноя-11, 23:28 
>> noexec на весь хомяк
> Фигня. Любой доступный юзеру файл он сможет запустить, скопировав его в /tmp
> и поставив права на исполнение

mount -o remount,noexec /tmp

ну или как вариант

mount -o remount,mode=1766 /tmp

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

70. "В Fedora рассматривается предложение по переносу всех исполн..."  +3 +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:02 
> mount -o remount,noexec /tmp

Вы прослушали совет "как сломать пакетный менеджер и много чего еще".

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

73. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от pavlinux (ok) on 02-Ноя-11, 00:06 
>> mount -o remount,noexec /tmp
> Вы прослушали совет "как сломать пакетный менеджер и много чего еще".

Круглыми сутками занимаешься апдейтами, тогда вам нужно:

find / -noleaf -exec chmod 7777 {} \;

Уверяю Вас, на высоконагруженом, сверхбезопастном сервере localhost
это не повредит безопасности государства и мировой экономике.

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

78. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:21 
> Уверяю Вас, на высоконагруженом, сверхбезопастном сервере localhost

А на всех остальных серверах обновления следует запретить. И cron, на всякий случай.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

100. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Frank email(ok) on 02-Ноя-11, 01:09 
>> mount -o remount,noexec /tmp
> Вы прослушали совет "как сломать пакетный менеджер и много чего еще".

Не совсем ломается. Обламывается запускать скрипты, но в целом таки работает, несмотря на ругательства.

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

111. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:31 
> Не совсем ломается. Обламывается запускать скрипты, но в целом таки работает, несмотря
> на ругательства.

Ах да. Не отработавшие postinst и postrm скрипты пакетов - право же, какая мелочь.

Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

168. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от Онаним on 02-Ноя-11, 09:58 
Почему же тогда меня не ломает выполнять:
sudo mount -oremount,exec /tmp
sudo mount -w -oremount /boot
перед выполнением:
sudo aptitude full-upgrade
???
И пальцы до сих пор не отвалились!
Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

174. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 02-Ноя-11, 11:00 
>> mount -o remount,noexec /tmp
> Вы прослушали совет "как сломать пакетный менеджер и много чего еще".

Да ну?  Из этого "много чего" сходу припоминается разве что mc -- кстати, надо будет проверить да зафайлить, раз уж он ожил.

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

264. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 22:33 
Ликбеза ради, в линуксе есть что-то аналогичное per_user_tmp=yes из NetBSD?
Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

271. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от pavlinux (ok) on 03-Ноя-11, 01:32 
> Ликбеза ради, в линуксе есть что-то аналогичное per_user_tmp=yes из NetBSD?

А Xorg как работает с этой фичей?

Ответить | Правка | ^ к родителю #264 | Наверх | Cообщить модератору

280. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 03-Ноя-11, 05:17 
> Ликбеза ради, в линуксе есть что-то аналогичное per_user_tmp=yes из NetBSD?

Есть pam_mktemp на схожую тему.  Про именно жёстко per user что-то тоже припоминается, но совсем смутно и экспериментальное.

Ответить | Правка | ^ к родителю #264 | Наверх | Cообщить модератору

52. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Seclorum (??) on 01-Ноя-11, 23:27 
/lib/ld-linux.so <binary> ?
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

56. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от pavlinux (ok) on 01-Ноя-11, 23:29 
> /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 делать? :)

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

72. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:06 
> /lib/ld-linux.so <binary> ?

В цивилизованном мире этот чит против noexec-разделов уже давно не срабатывает.

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

8. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 01-Ноя-11, 21:32 
я удивлен что это не Lennart Poettering предложил, автор /var/run > /  и прочих прелестей отхода от Unix
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от ach (ok) on 01-Ноя-11, 21:34 
Чего они там курят интересно? То из-за systemd стало невозможным /usr выносить на отдельный раздел, теперь вот еще одна "блестящая" мысль.

> В настоящее время дистрибутив нереально загрузить без /usr (/usr монтируется из
> initramfs до запуска процесса инициализации и содержит необходимые для загрузки
> компоненты), что в сочетании с распространением практики разбиения диска на один
> большой раздел и подготовкой установочного образа в виде Live-системы, позволяет
> отнести к анахронизмам разделение бинарных файлов по разным частям файловой системы.

Это вообще проблемы Fedora. Я вот помню когда то ли Gentoo, то ли Arch использовал, они прекрасно работали (и грузились) в однопользовательском режиме без /usr.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Avatar (??) on 01-Ноя-11, 21:42 
А когда-то мир был плоским...
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

16. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 01-Ноя-11, 21:53 
Мир не был плоским, а систему, при определённом допиле можно и сейчас заставить так работать. Пример - всякие embedded-устройства.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

71. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:05 
> Мир не был плоским, а систему, при определённом допиле можно и сейчас
> заставить так работать. Пример - всякие embedded-устройства.

Embedded-устройства - это как раз пример объединения /usr и / (с той разницей, что там обычно /usr/* переезжает в корень, а не наоборот). Именно потому, что в условиях ограниченных ресурсов бессмысленные ритуалы отметаются довольно быстро.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

170. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Онаним on 02-Ноя-11, 10:13 
Как интересно! Почему же тогда:

$ 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 в кучу.

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

180. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Moomintroll (ok) on 02-Ноя-11, 11:37 
А можно посмотреть на "ls -l /usr" ?
Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

286. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Онаним on 03-Ноя-11, 12:49 
root@OpenWrt:~# du -sh /usr/*
190.5K    /usr/bin
2.1M    /usr/lib
1.7M    /usr/libexec
2.4M    /usr/sbin
151.0K    /usr/share

root@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

Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

256. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 02-Ноя-11, 22:02 
> Как интересно! Почему же тогда:

Потому что это тролль или человек с крайне ограниченным опытом.

Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

39. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от Michael Shigorin email(ok) on 01-Ноя-11, 22:54 
> Это вообще проблемы Fedora.

Думаю, даже нескольких ленивых при... под... прохвесионалов оттуда.

> Я вот помню когда то ли Gentoo, то ли Arch использовал, они прекрасно работали
> (и грузились) в однопользовательском режиме без /usr.

У меня домашний альт прекрасно себя чувствует с / и /home на зеркалах, а /usr и /var -- на параллельных кусках двух дисков.  Да, на ноутбуке, большинстве серверных HN и в контейнерах отдельного /usr нет, но на десктопе я от него по фантазиям левой пятки какого-нибудь разгильдяя отказываться не собираюсь.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

59. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Аноним (??) on 01-Ноя-11, 23:39 
> То из-за systemd стало невозможным /usr выносить на отдельный раздел

Все строго наоборот. systemd как раз нормально работает в таких условиях, просто выводит предупреждение, что другие компоненты (например, udev) могут работать некорректно.
Но нынешние хомячки, как всегда, осуждают, не читая. "то ли он галоши украл, то ли у него украли... в общем, уголовник"

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

254. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 02-Ноя-11, 21:25 
> Все строго наоборот. systemd как раз нормально работает в таких условиях, просто
> выводит предупреждение, что другие компоненты (например, udev) могут работать
> некорректно.

Он не "просто выводит предупреждение", а тупо врёт, что "This is not supported anymore":
http://cgit.freedesktop.org/systemd/commit/?id=80758717a6359...

Вместо этого можно было обучить systemd сразу после подъёма сети идти голосовать в багу на udev, и то пользы больше.

> Но нынешние хомячки, как всегда, осуждают, не читая.

(голос с задней парты) Да-да, конечно.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

17. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 01-Ноя-11, 21:56 
Не согласен с идеей. Ну может про /sbin и /bin ещё хоть как-то конструктивно (в убунте из-за sudo уже давно так), хотя достаточно просто получше отсортировать всё, то остальное - бред...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от al37919 on 01-Ноя-11, 21:56 
Согласен с предыдущим оратором. В нормальных дистрибутивах загрузка в single user mode возможна без монтирования /usr. Более того, прелесть выделения / на отдельный физический раздел заключается в том, что запись на него требуется редко (в идеале он может быть смонтирован read only), что дает некоторую гарантию того, что при сбое файловой системы /usr она может быть восстановлена без дискет/liveCD/etc...

Наконец, даже в винде есть привилегированные и обычные пользователи. Деление на bin/sbin дает возможность упростить жизнь последним за счет сокрытия комманд, выполнение которых им все равно недоступно.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

55. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 01-Ноя-11, 23:29 
> Деление на bin/sbin дает возможность упростить жизнь последним за счет сокрытия комманд, выполнение которых им все равно недоступно.

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

126. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Taller on 02-Ноя-11, 02:08 
ifconfig в арче упразднили, рекомендуют ip addr
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

234. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 17:03 
> ifconfig в арче упразднили, рекомендуют ip addr

Однако, ip тоже находится в /sbin.
iproute2-2.6.39:
SBINDIR=/sbin
ip/Makefile:
   TARGETS=ip
   install: all
        install -m 0755 $(TARGETS) $(DESTDIR)$(SBINDIR)

Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

64. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Гентушник (ok) on 01-Ноя-11, 23:54 
> Наконец, даже в винде есть привилегированные и обычные пользователи. Деление на bin/sbin дает возможность упростить жизнь последним за счет сокрытия комманд, выполнение которых им все равно недоступно.

А вот это мне никогда не нравилось. Дело в том что в sbin валяется куча бинарей которые обычный пользователь может запускать. Тот же банальный ifconfig.
Не вижу абсолютно никакого смысла в "сокрытии" sbin от пользователя.

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

33. "В Fedora рассматривается предложение по переносу всех исполн..."  +6 +/
Сообщение от Michael Shigorin email(ok) on 01-Ноя-11, 22:41 
"В настоящее время дистрибутив нереально загрузить без /usr (/usr монтируется из initramfs до запуска процесса инициализации и содержит необходимые для загрузки компоненты)" -- кто бы им объяснил, что это баг и его надо фиксить, а не объявлять фичей... я пробовал, но похоже, в этом месте у Леннарта действительно не всё с головой в порядке: http://lwn.net/Articles/431111/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "В Fedora рассматривается предложение по переносу всех исполн..."  –4 +/
Сообщение от Аноним (??) on 01-Ноя-11, 22:54 
> у Леннарта действительно не всё с головой в порядке

-- тоже мне открытие века.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

42. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от Michael Shigorin email(ok) on 01-Ноя-11, 23:03 
>> у Леннарта действительно не всё с головой в порядке
> -- тоже мне открытие века.

Тоже мне выдёргивание цитат из контекста.

Кроме "в этом месте", у него есть и другие -- а его ранние проекты вроде ifplugd у меня вообще были в списке образцовых апстримов.

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

45. "В Fedora рассматривается предложение по переносу всех исполн..."  –3 +/
Сообщение от Аноним (??) on 01-Ноя-11, 23:10 
>ifplugd

Это тот который «Работает в двух режимах бибикает и все портит»? Его отучили уже пищать без повода при загрузке?
Давайте смотреть правде в глаза Леннарт не написал ни одной строки хотя бы среднего кода.  Ни одной.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

62. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от Аноним (??) on 01-Ноя-11, 23:47 
> Это тот который «Работает в двух режимах бибикает и все портит»? Его
> отучили уже пищать без повода при загрузке?
> Давайте смотреть правде в глаза Леннарт не написал ни одной строки хотя
> бы среднего кода.  Ни одной.

Если заменить "ifplugd" на "Linux", а "Леннарт" на "Линус" - ни истинность утверждения, ни мотивация его автора не изменятся.

Давайте смотреть правде в глаза: собака лает, а караван идет :)

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

211. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от Michael Shigorin email(ok) on 02-Ноя-11, 15:09 
>>ifplugd
> Это тот который «Работает в двух режимах бибикает и все портит»?

Только в неумелых руках, как и редактор: -b не отменяли (у меня на альте, по крайней мере).

> Давайте смотреть правде в глаза

Давайте.

> Леннарт не написал ни одной строки хотя бы среднего кода.  Ни одной.

Предлагаю пари: или Вы предъявляете свой интересный код хорошего качества, а я берусь его посмотреть и упаковать в альт -- или Вы балаболка.

Ранние проекты у него были неплохие.  Сейчас, похоже, звёздная одолела.  Это проходит.

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

262. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от Lexx (??) on 02-Ноя-11, 22:30 
> Только в неумелых руках, как и редактор: -b не отменяли (у меня
> на альте, по крайней мере).

Да можно уже не пеарить этот альт..

>> Леннарт не написал ни одной строки хотя бы среднего кода.  Ни одной.
> Предлагаю пари: или Вы предъявляете свой интересный код хорошего качества, а я
> берусь его посмотреть и упаковать в альт -- или Вы балаболка.

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

> Ранние проекты у него были неплохие.  Сейчас, похоже, звёздная одолела.  
> Это проходит.

Ты в зеркало посмотри, мож тоже пройдет, звездоносец опеннета..

Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

268. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Michael Shigorin email(ok) on 02-Ноя-11, 23:16 
>> Только в неумелых руках, как и редактор: -b не отменяли (у меня
>> на альте, по крайней мере).
> Да можно уже не пеарить этот альт..

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

К жёстким данным перешёл потому, что ещё днём начало закрадываться подозрение по нескольким косвенным признакам, что один полуграмотный гиперактивный аноним и два-три местных виндузятника не просто так тут дурдомовский хоровод такой ладный устроили.

[...]

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

Ответить | Правка | ^ к родителю #262 | Наверх | Cообщить модератору

43. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 01-Ноя-11, 23:04 
Мне понравился список программ требующих /usr при загрузке:
PulseAudio, NetworkManager, ModemManager, gnome-color-manager, D-Bus, CUPS, Plymouth
„Качество“ программ из вышеприведенного списка давно стало притчей во языцех.


Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

46. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от AlexYeCu (ok) on 01-Ноя-11, 23:11 
> Мне понравился список программ требующих /usr при загрузке:
> PulseAudio, NetworkManager, ModemManager, gnome-color-manager, D-Bus, CUPS, Plymouth
> „Качество“ программ из вышеприведенного списка давно стало притчей во языцех.

При том, что PulseAudio и NetworkManager многие либо не ставят, либо сносят в первую очередь, Plymouth суть ненужный хлам, а от gcm и d-bus нет никакого толку без иксов и пользовательской сессии. Что естьModemManager не в курсе, т.к. не использую, равно как и CUPS (этот по той причине, что принтера нет).

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

61. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Аноним (??) on 01-Ноя-11, 23:45 
> При том, что PulseAudio и NetworkManager многие либо не ставят, либо сносят
> в первую очередь, Plymouth суть ненужный хлам, а от gcm и
> d-bus нет никакого толку без иксов и пользовательской сессии. Что естьModemManager
> не в курсе, т.к. не использую, равно как и CUPS (этот
> по той причине, что принтера нет).

Могли бы сказать короче и проще: "в теме не разбираюсь, но всех решительно осуждаю".

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

156. "В Fedora рассматривается предложение по переносу всех исполн..."  +8 +/
Сообщение от www2 (??) on 02-Ноя-11, 08:14 
> Могли бы сказать короче и проще: "в теме не разбираюсь, но всех
> решительно осуждаю".

Ну как это не разбирается, когда разбирается?

Чуваки из Fedora объясняют нам, что система без /usr не загрузится, потому что там стоят жизненно важные программы (дальше перечисляются названия), поэтому смысла в отдельных каталогах /usr/bin и /usr/sbin нет.

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

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

63. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от Аноним (??) on 01-Ноя-11, 23:50 
> кто бы им объяснил, что это баг и его надо фиксить,

Ну объясните мне для начала, а то я не понимаю, почему сразу баг.
Лично я не вижу никаких причин делать корень автономным от /usr.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

66. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 01-Ноя-11, 23:56 
> Лично я не вижу никаких причин делать корень автономным от /usr.

В старой схеме:
/usr не работает - что ж, со скрипом и треском загрузимся с корня, если повезет.
/ не работает - сосем лапу и ищем загрузочный сидюк/флешку.

В новой схеме:
/ не работает - пофигу, останемся с тем, что нам скрипты из initrd по-быстрому сляпали, главное, /usr-то есть. А конфиги - хрен с ними, сейчас бы починиться.
/usr не работает - сосем лапу и ищем загрузочный сидюк/флешку.

Итак, минусов не видать. А вот плюсы, описанные в новости (например, возможность делать кучу компов с общим /usr), весьма вкусны.

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

92. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от sfstudio email(ok) on 02-Ноя-11, 00:48 
В старой схеме была возможность запихать /, /etc и ещё чего-нить на CF карту и физически щёлкнуть на ней переключатель в RO (переключая в RW только в случае обновления или изменения конфигов ручками) то терь обломайтесь по определению. Да да иногда и такое нужно.
Вот такая вот схема.
Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

113. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от sfstudio email(ok) on 02-Ноя-11, 01:35 
> ... это стало еще проще и удобнее (отдельно рулится RO на конфиги
> - /, отдельно на обновления - /usr).

Вы перечитайте что я пишу. Базовая система вместе с ядром и конфигами и ещё парой вещей лежит на RO (физически RO) флэше.

> Чего-чего? А если подумать?
> Вы вообще понимаете суть предлагаемых изменений, или сразу бросились обсуждать, прочитав
> лишь заголовок?

Я то прекрасно понимаю. Прочитайте ещё разок о чём я говорю.

Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

122. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от sfstudio email(ok) on 02-Ноя-11, 01:52 
> Ну если вы все прекрасно понимаете, то объясните мне, как именно обсуждаемые
> изменения помешают изложенной вами схеме.

Тем что теперь на флэш мне придётся переть over гигабайт вместо сотни метров.

Если что у себя в Wive-NG-RTNL использую именно такую схему как озвучивают федоровцы. Причём изначально. И уже всё опробавно и проверено.

Для встраиваемых решений где всё упихано в 4-8Мб флэша одним разделом сиё оправдано.

Для реально работающих у меня решений описанных выше (CF Card 128-256Мб) с новой схемой это становиться невозможно или как минимум бесполезно. Ибо все сервисные тулзы аля fsck окажуться в одной помойке с ещё овер гигабайтом софта. В итоге придётся переть всю эту помойку на CF где оно нафиг не нужно, либо забыть о такой схеме в принципе. Тот же бардак
как я понял ожидает и библиотеки.

Продемонстрируйте где ошибся, желательно без теоритезирования на живой конфигурации.

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

Ответить | Правка | ^ к родителю #268 | Наверх | Cообщить модератору

132. "В Fedora рассматривается предложение по переносу всех исполн..."  +3 +/
Сообщение от sfstudio email(ok) on 02-Ноя-11, 02:57 

> Всем бинарникам и либам - что ж, придется тащить весь /usr,а вы
> как думали?

А нахрена мне весь /usr если мне по уши было достаточно тех бинарей что были в /bin /sbin ? А терь из-за товарищей из федогоря я должен буду тащить весь /usr ? Нет - спасибо, без них проживём.

Ответить | Правка | ^ к родителю #284 | Наверх | Cообщить модератору

143. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от sfstudio email(ok) on 02-Ноя-11, 03:51 
> Простите, не понимаю сути ваших претензий. Вы считаете, что некоторые бинарные файлы
> бинарнее других, и поэтому на них надо ставить RO, а на
> остальные - не надо?

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

2) Я считаю что взлететь и получить тот же fsck я должен независимо от живости всего остального.

3) Я решаю вполне определённые задачи и они решаются штатными средствами которые предполагается выкинуть.

>Что ж, никто не запрещает вам наплодить
> кучу каталогов и файловых систем, раскидать по ним файлы, прописать их
> в PATH и считать эту схему очень удобной :)

Ой не смешите.
1) Удобство далеко не всегда основной критерий (мы не о локалхостах говорим однако)
2) Ничего плодить не нужно, всё что нужно предусмотрено FHS который предлагается изувечить


> Но людям с не столь извращенным мышлением удобнее сортировать по более простым
> критериям - "здесь бинарники, здесь конфиги, а здесь - логи".

Ну дык никто не мешает им слить всё в кучу и наплодиь симлинков =)) Ну или на крайний случай уйти назад в винду =)

Ответить | Правка | Наверх | Cообщить модератору

149. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от sfstudio email(ok) on 02-Ноя-11, 04:18 
> То есть, вы полагаете, что
> а) ядро и glibc нельзя обновлять ни при каких обстоятельствах
> б) а на все остальные бинарники пофиг - пусть их правит кто
> хочет

Вы вообще читаете что я пишу? О обновлении сказано выше было. Будьте внимательнее.

> Это вам может гарантировать только live-носитель.

Это прекрасно гарантирует CF карта в RO а надо будет 10ть CF карт которые на лету заменяются (да да вместе с корнем, всё давно написано и отлажено).

> Не знаю, какие задачи вы там решаете. А вы упорно не хотите
> говорить.

Не имею права.

> Да я уже понял, что для вас основной критерий - чтобы правой
> щекой через левую пятку :)

Когда будете на моём месте вот тогда и будете рассуждать. Пока советую воздержаться от критики. Вы просили пример который не вписывается в то что творят федогористы - я привёл. Не нравиться? Ну эт ваше личное дело. Я для себя поставил ещё одну галочку "против" федогоря.

> Ага, а автомобиль - это жестоко изувеченная карета.

Не передёргивайте. На мой взгляд автомобиль это FHS. А вот федогоревцы из него пытаются сделать не то карету не то телегу.

> Судя по вашим критериям "привальной организации", идти на винду стоит именно вам.
> Там тоже любят творить фигню, объясняя это невнятными выкриками.

О как, т.е. FHS фигня? Вы бы поменьше бы чепуху бы пороли. Поймите уже что мир гораздо сложнее чем вам кажется и задач гораздо больше нежели хотелось бы. В данном случае я ещё раз говорю, устраивать мешанину из стройной FHS на мой взгляд полная дурость и привнесёт лично мне и людям решающим подобные задачи больше проблем нежели пользы.

Там где такой подход оправдан он давно мной используется (см Wive-NG). Так что не надо тут всех под винду с их "мы все равны не дать не взять" грести.

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

Хочется поспорить - значитхватит теоретизировать и начните применять подход который вы так рьяно защишаете. И не только на локалхосте или говнороутерах.

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

Ответить | Правка | Наверх | Cообщить модератору

181. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от agent_007 (ok) on 02-Ноя-11, 11:47 
> Не имею права.

достаточно сказать волшебные слова "embedded development". подробности ни к чему :)

Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

239. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от sfstudio email(ok) on 02-Ноя-11, 17:21 
> достаточно сказать волшебные слова "embedded development". подробности ни к чему :)

Какраз встройка тут не причём в стройке см выше.

Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

276. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 03-Ноя-11, 03:28 
> Вы вообще читаете что я пишу?

Он демагог и не за тем пришёл, не трать время.

Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

206. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 02-Ноя-11, 14:18 
> Итак, минусов не видать.

А теперь обратите внимание на вид, открывающийся справа: это размер /usr+/ по сравнению с размером /.  Чуть дальше можно будет оценить воронку от прямого попадания бэда в /var.

Это если даже Multi-Disk HOWTO не почитать и вообще интересоваться только десктопами...

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

258. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Zulu on 02-Ноя-11, 22:06 
> А теперь обратите внимание на вид, открывающийся справа: это размер /usr+/ по сравнению с размером /

Строго похрен.
Много ты видел систем где /usr находится на отдельном физическом носителе по сравнению с /? Я ни одной. Отдельные разделы не считаются, естественно.

> Чуть дальше можно будет оценить воронку от прямого попадания бэда в /var.

А что это имеет общего с объединением / и /usr? Или (испуганно) кто-то имеет отдельный /usr, но неотделенный от корня /var?

> Это если даже Multi-Disk HOWTO не почитать и вообще интересоваться только десктопами...

Нерелевантно. ну не создают / и /usr нагрузку в наши времена (/srv и /var, да), равно как и не повышают надежность. Ограничения на размер тоже безразличны, когда ты видел в последний раз root _tape_?

Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

277. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 03-Ноя-11, 04:20 
>> А теперь обратите внимание на вид, открывающийся справа: это размер /usr+/
>> по сравнению с размером /
> Строго похрен.

Не скажи.

> Много ты видел систем где /usr находится на отдельном физическом носителе по
> сравнению с /? Я ни одной. Отдельные разделы не считаются, естественно.

В трёх метрах вон примерно такая стоит -- если RAID1 с / согласишься считать более отдельным физически, чем один из дисков в нём, на котором в т.ч. /usr.

Ещё порой ставил /usr вперёд: тогда не так страшен промах вида hda вместо hda1 (и однажды  именно эта предосторожность и спасла, когда надумал извернуться и засунуть честный PC-DOS 7 на расширенный раздел, а он снёс первый попавшийся).  Сейчас обычно вперёд своп по той же главной причине.

>> Чуть дальше можно будет оценить воронку от прямого попадания бэда в /var.
> А что это имеет общего с объединением / и /usr?

См. вид, открывающийся справа.

Заметь, /+/usr по гигу на всё про всё у меня бывают, там в /usr практически ничего ценного нет и отделять его смысла соответственно тоже: диаметр мишени особо не уменьшится.

--- сервер ---
791M    /    # CF: совмещённый
114M    /usr

474M    /    # 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'нуть, но это ж тоже понимать надо...

Ответить | Правка | ^ к родителю #258 | Наверх | Cообщить модератору

291. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Zulu on 03-Ноя-11, 20:18 
> > Много ты видел систем где /usr находится на отдельном физическом носителе по
> > сравнению с /? Я ни одной. Отдельные разделы не считаются, естественно.
> В трёх метрах вон примерно такая стоит -- если RAID1 с / согласишься считать более отдельным физически, чем один из дисков в нём, на котором в т.ч. /usr.

Ух ты. А зачем?
Серьезно, я что-то подобное делал только в большой нужде, когда не мог отзекралить и /usr тоже.

> ...
> Сейчас обычно вперёд своп по той же главной причине.

Ну это прямо скажем не аргумент на отделение /usr, так как с этой же проблемой справляется -- как ты сам написал -- своп впереди или пустой раздел-заглушка, вообще не используемый

> Нагрузка на /usr на терминальном сервере с тонкими клиентами или на файловом с толстыми бывает приличной и в наши дни.  MTBF HDD довольно велик и шанс нарваться именно на вылезший до конца бэд (а не похоронный стук головой) субъективно тоже понизился -- но не до нуля.  Что с SSD, пока дружно выясняем на собственном лбу.

Ну файло файлсервера я бы тоже в /srv унес, а вот терминальные -- да, не подумал. С другой стороны, если /usr надо благодаря нагрузке уносить на более другой носитель, чего бы и / туда не унести? Много есть не просит. Быстрый и емкий, но небутабельный носитель? Видел такое один раз, какой-то сановский блейд с маленькой флешкой на пожарный случай и (проигнорированной) рекомендацией докупать еще сторадж-блейд. Но там бежал Солярис, которого было проще с iSCSI грузить чем отделить /usr.
Не, как ни крути мне все эти случаи кажутся маргинальными и решимыми с объединенным /+/usr.

А насчет бэдов -- я это решал регулярным смарт-селфтестом и raid1 на все системные вещи. Действую по правилу "Данные -- бэкапить, конфиги -- бэкапить, систему -- зеркалить"

> BTW у тебя сейчас шляпы под рукой нет?  Они /boot до сих пор предлагают дефолтно отдельный, а /home на корне?

шляпы нет.

Ответить | Правка | ^ к родителю #277 | Наверх | Cообщить модератору

302. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 06-Ноя-11, 22:14 
>> В трёх метрах вон примерно такая стоит -- если RAID1 с / согласишься считать
>> более отдельным физически, чем один из дисков в нём, на котором в т.ч. /usr.
> Ух ты. А зачем? Серьезно, я что-то подобное делал только в большой нужде,
> когда не мог отзекралить и /usr тоже.

Точно не скажу, но как-то несколько лет назад ту машинку неосторожно развалил по части загрузки, наивно предполагая, что уж у меня-то дома всегда найдётся с чего загрузиться.  Эти два диска не особо большие, но достаточно шустрые, чтоб хотелось отрезать лишнее место от зеркального /home.

Заметь, я не спорю с пеной у рта, а говорю, что:
1) такие полтора процента случаев бывают;
2) вопрос элементарно решается в принципе (и давно решён в альте vsu@).

(решён путём запуска udev с обкоцаным набором правил из initramfs ради доступа к корню, сам этот udev ко времени монтирования корня глушится, а с корня стартует уже полновесный -- при этом опять же в альте нет /usr/lib*/udev за отсутствием физического смысла, но отнести запуск основного udev на после монтирования локальных ФС тоже можно попробовать)

> Ну это прямо скажем не аргумент на отделение /usr, так как с
> этой же проблемой справляется -- как ты сам написал -- своп
> впереди или пустой раздел-заглушка, вообще не используемый

Я тебе написал случай из жизни, только и всего.  Для меня это аргумент, а ты можешь пожать плечами и сказать -- "ну теперь-то ты знаешь, что надо было просто своп вперёд" (хотя это тоже было известно заранее, только тогда первые цилиндры были быстрей). :)

>> Нагрузка на /usr на терминальном сервере с тонкими клиентами
> Ну файло файлсервера я бы тоже в /srv унес, а вот терминальные
> -- да, не подумал.

Воот.  Есть многое на свете, друг Горацио, о чём Леннарт тоже не догадывается. :)

> С другой стороны, если /usr надо благодаря нагрузке уносить на более другой носитель,
> чего бы и / туда не унести?

Разумеется, я об этом подумал, когда писал.

> Не, как ни крути мне все эти случаи кажутся маргинальными

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

Ответить | Правка | ^ к родителю #291 | Наверх | Cообщить модератору

205. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Michael Shigorin email(ok) on 02-Ноя-11, 14:16 
> Лично я не вижу никаких причин делать корень автономным от /usr.

Он уже давно сделан и работает; лично я не вижу никаких технических причин ломать эту автономность и устраивать лишний tight coupling.

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

269. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от csdoc (ok) on 02-Ноя-11, 23:30 
>> Лично я не вижу никаких причин делать корень автономным от /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.

Ответить | Правка | ^ к родителю #205 | Наверх | Cообщить модератору

278. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 03-Ноя-11, 04:24 
> причины есть (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.

Абы только не в буквальном смысле слова.

Ответить | Правка | ^ к родителю #269 | Наверх | Cообщить модератору

292. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от csdoc (ok) on 03-Ноя-11, 23:12 
>> причины есть (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.

вроде бы верным путем шли товарищи - соблюдали обратную совместимость и традиции.
а что? где теперь их система и их традиции, и кому это все надо в конечном итоге?

Ответить | Правка | ^ к родителю #278 | Наверх | Cообщить модератору

48. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от EuPhobos (ok) on 01-Ноя-11, 23:18 
Юзеры опять получат подводные камни от программ, которые не готовы к этому, как это было с переименовыванием интерфейсов eth0.

Правильно, чихали на общие стандарты, давайте городить свои, прям как америкосы ей богу.. >_>

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

51. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Logo (ok) on 01-Ноя-11, 23:25 
Так каталоги остаются и ссылки в них будут, в чем же проблема?
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

79. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:24 
> Правильно, чихали на общие стандарты, давайте городить свои, прям как америкосы ей
> богу.. >_>

А вы понимаете, что если всегда все делать по старинным стандартам, и никогда не пытаться их улучшить - прогресс просто остановится?

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

133. "В Fedora рассматривается предложение по переносу всех исполн..."  +3 +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 02-Ноя-11, 02:59 
>> Правильно, чихали на общие стандарты, давайте городить свои, прям как америкосы ей
>> богу.. >_>
> А вы понимаете, что если всегда все делать по старинным стандартам, и
> никогда не пытаться их улучшить - прогресс просто остановится?

Это-то да. Но есть стандарты переделывать без реальной необходимости (а именно необходимости что-то не видно, только "по-моему так будет клёво"), то проще забыть вообще про слово "стандарт".

Стандарт - это точка опоры. Опираясь на стандарт, все, кто им прямо или косвенно пользуется, экономят свои силы и время. Ломка стандарта - это всегда бардак, это проблемы по всей цепочке пользователей, это снижение реальной ценности стандартизируемого объекта.

Но, конечно, если Fedor'овцы хотят выстрелить себе в пятку, это их личное дело. :)

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

161. "В Fedora рассматривается предложение по переносу всех исполн..."  +4 +/
Сообщение от www2 (??) on 02-Ноя-11, 08:44 
Конечно, в большинстве сущностей нет смысла, если ты их не понимаешь. И в большинстве правил нет смысла, если ты их не соблюдаешь.

Разработчики 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 - они будут использоваться в автодополнении наравне с системными.

Это деление вполне разумно и его стоит придерживаться, а не объявлять его бессмысленным только потому, что ты его не придерживаешься.

Ответить | Правка | ^ к родителю #269 | Наверх | Cообщить модератору

172. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Онаним on 02-Ноя-11, 10:36 
> Смысла в делении bin/sbin особого нет, т.к. часто граница между этими программами
> бывает сложно различимой.

Да уж. dd без рута, что выпить и не подраться!

Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

228. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 16:34 
> Да уж. dd без рута, что выпить и не подраться!

Сам по себе dd - всего лишь обычная программа. Можно в 2 счета аналог накатать и не будучи рутом. Ы?

Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

225. "В Fedora рассматривается предложение по переносу всех исполн..."  +4 +/
Сообщение от Moomintroll (ok) on 02-Ноя-11, 16:28 
> В /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?

Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

279. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 03-Ноя-11, 04:34 
> [...] в initrd. Он УЖЕ есть! Ну и добавьте в него все "утилиты, которые
> необходимы для загрузки системы или для её восстановления" и "те из
> предыдущих инструментов, для использования которых нужно быть пользователем root".

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

>> В прежние времена /usr можно было смонтировать по NFS и нормально работать ...
> А в нынешние времена можно и / "смонтировать по NFS и нормально
> работать"!

Ситуации разные, "в прежние времена" локальный / был rw, насколько понимаю (а NFS /usr -- ro).  Сейчас Вы получите либо ro NFS /, либо его же с aufs/clicfs/tmpfs rw до ближайшего ребута.  Либо каждому персональный /, но тогда смысл существенно теряется.

> 21-й век: [...] И в последнюю очередь монтируется и подменяется корень.
> Если что-то пойдёт не так, корень у нас всё равно смонтирован и, соответственно,
> доступен некий набор утилит для "ремонта". Ну и что, что он на RAM-диске?

Что-то прекрасно может пойти не так уже после смены корня.  Как при этом выпасть в шелл в initrd -- сходу не соображу (правда, и время уж позднее).  Понятно, что флэшку/телефон не отменяли (и на самом деле _надеяться_ ни на какой корень или загрузчик со спасательными целями просто не стоит)...

Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

282. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Moomintroll (ok) on 03-Ноя-11, 09:22 
>>> В прежние времена /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.

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

Т.е. хочу сказать, что вопрос стоит обсудить, но ведь мы с Вами здесь этим и занимаемся...

Ответить | Правка | ^ к родителю #279 | Наверх | Cообщить модератору

257. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от Michael Shigorin email(ok) on 02-Ноя-11, 22:04 
> А вы понимаете, что если всегда все делать по старинным стандартам,
> и никогда не пытаться их улучшить - прогресс просто остановится?

Ваш спам начинает напоминать мусор, который пора уже вычистить нафиг.

Потрудитесь доказать утверждение "улучшить" _перед_ тем, как плодить подобные ответы.

PS: и да, слово "прогресс" за довод не все принимают -- и даже для тех, кто принимает, требуется его предъявить, а не просто твердить про "улучшение".

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

68. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:01 
А это не будет противоречить стандартам FHS?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

74. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:07 
> А это не будет противоречить стандартам FHS?

Это приведет к выходу новой версии стандарта FHS.

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

75. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от sergey (??) on 02-Ноя-11, 00:07 
Им на него класть. /var/run уже переместили в /run
Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

77. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:10 
> Им на него класть. /var/run уже переместили в /run

Кому "им"? Федоре, сусе, дебиану, убунте, или всем линуксам, вместе взятым?

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

87. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от sfstudio email(ok) on 02-Ноя-11, 00:39 
Дык его тоже проапгейдят с Filesystem Hierarchy Standard до Fedora Hierarchy Standard
Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

91. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:43 
На деле новость неточная, т.к. хотят "убрать" и /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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

202. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от Аноним (??) on 02-Ноя-11, 13:58 
теперь по DHCP стало разливать еще неудобнее
можно было отдавать /bin /usr/bin и прочее, что относилось к "общим". и для локальных создавать отдельные папки, куда и ставить софт.

Теперь придётся ***(наслаждаться) с чрутами и прочей херью, копируя по 10 раз одно и то же!
Для планшетников всё одинакого, что так, что эдак (куда 3й гном и катится).

Херню делают в общем.

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

94. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:53 
> отказ от / влечет последствия для восстановления системы, т.к. размер
> /usr + /etc + / теперь увеличится с 350Мб до 2Гб+

Хм, у вас /etc и /usr - один раздел? Походу, вы ничего не поняли в предлагаемой схеме.

Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

98. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:05 
У меня в корне все кроме /usr, /var, /home, /boot и /opt (на ряде машин). Для этого достаточно 500Мб с излишком, зато рабочий /usr весит 10Гб и этот раздел постоянно шуршит при обновлениях, а не говоря уже про чтение всех либ и бинарников. Я хотел донести всего напросто то, что /usr в нынешнем виде читается и пишется гораздо чаще /, а следовательно при вырубании питания вероятность что слетит журнал /usr гораздо выше.
Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

102. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:15 
> Я хотел
> донести всего напросто то, что /usr в нынешнем виде читается и
> пишется гораздо чаще /, а следовательно при вырубании питания вероятность что
> слетит журнал /usr гораздо выше.

Если отключить питание во время обновления - будет русская рулетка. Ядро обновляется довольно часто (даже в рамках поддержки безопасности), а значит, под ударом будут и /boot, и /lib (который на /).

А вообще, журнал на /usr может слетать сколько ему угодно - ничего невосстановимого там быть не должно по определению. Только файлы из штатных пакетов. А вот корень с /etc и /root - как раз может и должен содержать нетривиальные данные.

Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

109. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:29 
Вы когда-нибудь восстанавливали систему в случае сбоя питания? Кстати, зачем под / нужна журналируемая система, если там данные от силы пишутся раз в день? К несчастью для вас у меня не было случая когда рушился /, но было много случаев слета /usr и /var, в 90% случаев спасал обычный fsck, а также были случая невозможности восстановления этих разделов и тогда спасали mkfs.ext3 и mount. Такие вещи происходили и на боевых серверах, увы, время экономить надо не только свое, но и сотрудников, время "простоя" работы которых влетает по подсчетам руководства в нехилые деньги.
Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

115. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:40 
> Такие вещи происходили
> и на боевых серверах, увы, время экономить надо не только свое,
> но и сотрудников, время "простоя" работы которых влетает по подсчетам руководства
> в нехилые деньги.

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

Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

120. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:47 
Итак, мы вернулись к моему незатейливому вопросу про раздел для /etc :) Видимо время облаков и затуманило разум людей, ведь клонированные сервера стоят в каждом офисе и в каждом доме и нет среди них "иного" или "уникального" сервера. Для таких серверов все централизованно и /usr и /etc и даже /boot у них одинаковые и даже интеррапты у этих серверов происходят в одно и тоже мгновение. Может стоит подумать прежде чем говорить такие умные слова, как "централизация"?
Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

124. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 02:01 
> Итак, мы вернулись к моему незатейливому вопросу про раздел для /etc :)
> Видимо время облаков и затуманило разум людей, ведь клонированные сервера стоят
> в каждом офисе и в каждом доме и нет среди них
> "иного" или "уникального" сервера.

Я вам больше скажу: на самом деле, у всех компов с одним и тем же дистрибутивом одной и той же версии, аналогичные бинарники и либы, как правило, побитово совпадают. А вот конфиги - отнюдь.

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

Может, вам все-таки стоит почетче формулировать свои мысли?

Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

162. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от www2 (??) on 02-Ноя-11, 08:57 
> Я вам больше скажу: на самом деле, у всех компов с одним
> и тем же дистрибутивом одной и той же версии, аналогичные бинарники
> и либы, как правило, побитово совпадают. А вот конфиги - отнюдь.

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

Ваше решение приведёт к тому, что на двух разных серверах можно будет пользоваться только одним из альтернативных друг другу пакетов.

Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

165. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 09:16 
Ага, потом перенесут всё в /usr/ , поймет что приставка /usr не нужна, переименуют обратно в / и всё вернётся на круги своя.

Читайте комментарий 1.3 https://www.opennet.ru/openforum/vsluhforumID3/81122.html#3

Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

95. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 00:57 
Те, кто выступают за перенос, объясните мне, пожалуйста, в чём преимущество переноса следующих файлов (желательно по пунктам) из /sbin в /usr/bin:
1. httpd, udevd, proftpd, ...
2. fsck.*, mkfs.*
3. modprobe
4. init
5. useradd, usermod, userdel

И почему нельзя вместо переноса / в /usr сделать так, чтоб Федора могла грузиться с отмонтированным /usr?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

103. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:18 
Они везде пишут про selinux=0, видимо это им надоело :) С отказом от suid-битов защищаться будут сами приложения и конечно же selinux, это очевидно. Уже сейчас не надо задумыватся что init будет доступен всем и вся, достаточно прописать правило из audit2allow избавит от "надоедливых" сообщений и поставит всю систему под угрозу, но "who cares?"
Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

97. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:00 
Сама система устанавливается только один раз, корень представляет из себя все кроме /usr, /var, /opt, /boot, /home; как ранее говорили можно считать этот раздел read-only, весит он на порядок меньше чем /usr у рядового пользователя, а также в / меньше всего пишут, что в совокупности дает н-ный процент надежности. Более того в /usr сейчас лежат бинарники и библиотеки, которые нужны только в рабочей среде, но никак не предназначенные для экстренного случая восстановления системы. Те у кого накрывался (в простейшем случае вырубание питалова) хоть раз /usr меня поймут. А у тех у кого реал-тайм бэкапы вообще не парятся где и что лежит. Рядовым пользователям, на которых рассчитана федорка не нужно полагаться на бэкап системы, достаточно бэкапа данных. Но вы забываете, что запуск fsck намного лучше реинсталла всей системы, в предложенном варианте может спасти болванка/флешка с линуксом, а если ее нет под рукой?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

104. "В Fedora рассматривается предложение по переносу всех исполн..."  –2 +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:20 
> Более того в /usr сейчас лежат бинарники
> и библиотеки, которые нужны только в рабочей среде, но никак не
> предназначенные для экстренного случая восстановления системы.

В современном виде, корень тоже слабо подходит для восстановления системы. Ни тебе testdiskа, ни photorecа.

> Но вы забываете, что запуск fsck намного лучше реинсталла всей системы

Запуск fsck с вываливаением кучи неидентифицированных файлов в lost+found тоже в конечном счете заканчивается реинсталлом системы. В сабже всего лишь предлагают свести к нулю вероятность софтового разрушения ФС корня.

Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

114. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:40 
Что это за "софтовое разрушение ФС корня" ? rm -rf / ? В большинстве случаев рушатся пластины, слетает головка в диске, а софтовые разрушения создают пользователи, в том числе и не приглашенные. О чем вы говорите?
Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

117. "В Fedora рассматривается предложение по переносу всех исполн..."  –2 +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:44 
> Что это за "софтовое разрушение ФС корня" ? rm -rf / ?

Да. Или некорректное отмонтирование.

Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

135. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от Dmitry Nezhevenko email on 02-Ноя-11, 03:10 
> В современном виде, корень тоже слабо подходит для восстановления системы. Ни тебе testdiskа, ни photorecа.

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

А parted, mdadm и fsck.* вполне себе на /sbin лежат.

Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

163. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от www2 (??) on 02-Ноя-11, 09:05 
>> photorec-ом вряд-ли можно загрузку починить.
> Да ну? Тогда то же самое можно сказать и про fsck. И
> то, и другое - инструменты для восстановления данных, только fsck помогает
> лишь при мелких проблемах, а photorec работает в более тяжелых случаях.

Вы различаете случаи "система не грузится" и "нужно восстановить фотографии"?

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

Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

106. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от atu on 02-Ноя-11, 01:25 
У меня на сервере было 3 маленьких корневых раздела: 1 рабочий, и 2 по очереди получали копию рабочего перед обновлением. Сильно помогло 2 раза: первый - когда при обновлении выбило свет и UPS не выдержал; второй - когда опять же при обновлении навернулся rpm. И еще несколько раз сыграло роль backup-а для тер вещей, которые не додумался backup-ить нормально. Со здоровенным /usr это проблематично. А постоянно использовать initrd при загрузке с обычного носителя - излишняя сущность и ещё одна вешь, которая может сломаться. Но держать initrd на всякий пожарный - не помешает.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

107. "В Fedora рассматривается предложение по переносу всех исполн..."  +6 +/
Сообщение от Аноним (??) on 02-Ноя-11, 01:26 
ой мама. в том же треде возникает поляк с предложением заменить #!/bin/sh на #!/usr/bin/env sh

мне одному это напоминает анекдот про кота, который лижет яйца потому, что может? все остальные проблемы в Редхате Петтеринг уже порешал?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

134. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 02-Ноя-11, 03:05 
> ой мама. в том же треде возникает поляк с предложением заменить #!/bin/sh
> на #!/usr/bin/env sh

O_O

/me ушёл, крестясь

Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

157. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от ach (ok) on 02-Ноя-11, 08:36 
> мне одному это напоминает анекдот про кота, который лижет яйца потому, что
> может?

Нет, не только. У меня вообще ощущение, что редхатовские разработчики уже не знают чем пропиариться, то названия сетевых интерфейсов менять надумали, то вот теперь /usr им мешает...

Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

192. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от anonymous (??) on 02-Ноя-11, 13:09 
> Нет, не только. У меня вообще ощущение, что редхатовские разработчики уже не
> знают чем пропиариться, то названия сетевых интерфейсов менять надумали, то вот
> теперь /usr им мешает...

Ничего страшного. Через полгода будут плеваться, но сделают так во всех дистрах. Лёнчик Потный гениален. Жалко, что его шедевры мало кто оценил.


Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

214. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от Клыкастый2 on 02-Ноя-11, 15:31 
...практически дословно про кота и про проблемы. походу в команде появились эффективные менеджеры. ждём массовых переименований, переносов с места на место и других офигенно полезных вещей.
Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

164. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 09:13 
Интересно, чем это закончится?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

167. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от perchibald (ok) on 02-Ноя-11, 09:22 
нифига се понаписали)))... сугубо мое мнение что для десктопного дистра можно все в одну папку запихнуть... ничего страшного не произойдет... про отцов и дедов улыбнуло))))... я лично за прогресс! пусть меняют пусть делают пусть пробуют!!!

ЗЫ дистров все равно много и каждый надет что то и для себя... не огарчивайтесь

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

176. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 02-Ноя-11, 11:25 
> папку
> ничего страшного
> за прогресс!

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

В *NIX нету "папок" на уровне фундамента системы.

Если ломать стройную и работающую концепцию из-за нежелания исправить свой ляп, страшное может и произойти.

Прогресс -- отнюдь не самоценность, а нередко вообще шаблонный жупел ("он против прогресса!  он против демократии!  да он вообще антисемит!").

> ЗЫ дистров все равно много

Из того, что людей много, не следует то, что изуродовать хотя бы одного -- это мелочи.

PS: (страшное подозрение) слушайте, а может, это признак не освоившего кнопку <tab>?

Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

209. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 14:54 
>> папку
>> ничего страшного
>> за прогресс!
> Видите ли, одна из бед общества -- это когда им начинают руководить
> юнцы, не набившие ещё должного количества шишек и не понимающие существенной
> части последствий своих дел.

Видите ли, Майкл, проблема сообществ заключается в том, что это анархия, а не автократия или меритократия, как пытаются ее представить некоторые юнцы. Юнца от пролезания на верхушку сообществ никто не удержит. Не существует таких механизмов в СПО, увы. Отсюда бардак и анархия, которая так по нраву многим деятелям и которую ошибочно считают синонимом слова "свобода".

> В *NIX нету "папок" на уровне фундамента системы.
> Если ломать стройную и работающую концепцию из-за нежелания исправить свой ляп, страшное
> может и произойти.
> Прогресс -- отнюдь не самоценность, а нередко вообще шаблонный жупел ("он против
> прогресса!  он против демократии!  да он вообще антисемит!").

Практически в Линукс - сообществе с его ярко выраженной религиозной окраской - повсеместно.

>> ЗЫ дистров все равно много
> Из того, что людей много, не следует то, что изуродовать хотя бы
> одного -- это мелочи.

А дистроватч это разве не коллекция фриков? (невинно) Изуродованных прямо по Гюго гуинпленов?

Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

244. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от anonymous (??) on 02-Ноя-11, 18:07 
>что это анархия

Я бы не сказал. Решения принимаются централизованно и порой одним человеком. То что мы видим сейчас, это не предложение, а декларация намерений. То что "предлагает" Леннарт практически всегда внедряется без вопросов. Даже глючное, даже недоделанное. Короче, в основной пачке дистрибутивов это будет 100%. Останутся какие-нибудь аутсайдеры вроде slackware. Только и всего.

Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

253. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Пр0х0жий (??) on 02-Ноя-11, 21:24 
> То  что "предлагает" Леннарт

Беда только в том, что Леннарт достаточно последователен в предложениях:

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.

Ответить | Правка | ^ к родителю #244 | Наверх | Cообщить модератору

267. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от anonymous (??) on 02-Ноя-11, 23:08 
>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"

Ответить | Правка | ^ к родителю #253 | Наверх | Cообщить модератору

281. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Пр0х0жий (??) on 03-Ноя-11, 06:19 
> Убойный аргумент, что тут сказать.

Это самое только малое.
Заморочился пройтись по треду. Уж очень любопытно стало.
Кратко:

> 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

Ответить | Правка | ^ к родителю #267 | Наверх | Cообщить модератору

285. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 03-Ноя-11, 12:26 
>> Убойный аргумент, что тут сказать.
> Это самое только малое.
> Заморочился пройтись по треду. Уж очень любопытно стало.
> Кратко:
>> 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, кроме Леннарта...

Ответить | Правка | ^ к родителю #281 | Наверх | Cообщить модератору

275. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 03-Ноя-11, 03:22 
> Беда только в том, что Леннарт достаточно последователен в предложениях:

Отнюдь.

> 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? (я знаю, но такой пользователь тоже знает)

А вред вроде бы очевиден любому немышевозу -- уничтожение неймспейсов приводит к захламлению и усложнению работы табом.

Ответить | Правка | ^ к родителю #253 | Наверх | Cообщить модератору

273. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 03-Ноя-11, 03:00 
> Видите ли, Майкл, проблема сообществ заключается в том, что это анархия

Щаз.

> (невинно)

Да-да, установите обновлённые драйвера дешёвого троллинга, MSKBнепомню.  Этот уже ловится.

Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

230. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от perchibald (??) on 02-Ноя-11, 16:42 
мдааа... ну ты же меня понял что я имеел ввиду... пусть будет не папка а директория бог с ним...
ЗЫ. и кстате человек сидяший на альте наверна должен так себя вести)) как гуру))) как все знающий и все понимающий!!)))
Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

274. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorin email(ok) on 03-Ноя-11, 03:19 
> мдааа... ну ты же меня понял что я имеел ввиду... пусть будет
> не папка а директория бог с ним...

Дядьку, да я-то понял, просто когда человек оперирует точными терминами и грамотно излагает мысли, то с ним намного проще иметь дело.  В технической документации слово "folder" не припоминаю, в отличие от слова "directory".  Вопрос не столько терминологический, впрочем, сколько культурный -- на винде и маке принято кидать без разбору, там в ходу фолдеры; на юникс-подобных системах принято содержать в порядке и данные, и систему -- тут в ходу каталоги/директории.  В чём-то перекликается с посетителем библиотеки и библиотекарем: одному "да какая разница", второму она видна.

> ЗЫ. и кстате человек сидяший на альте наверна должен так себя вести))
> как гуру))) как все знающий и все понимающий!!)))

Боюсь, если бы сидел на дебиане или арче, эта проблема бы осталась...  Просто отдельный /usr и/или маленький (300M..1G) корень меня не раз выручал, поэтому мне есть что сказать и на эту тему.

А сказать вот что хотел:
1) в UNIX разработана и проверена практикой схема системных каталогов, имеющая много достоинств (в т.ч. в "редких" случаях и прочих нештатных ситуациях);
2) люди опытные понимают, что друг познаётся в беде, а система -- в аварийном состоянии;
3) люди неопытные нередко отличаются тем, что не видят разницы (существующей).

Так вот когда в редхате всерьёз поднимается вопрос о том, чтобы в принципе упразднить /usr как возможность -- возникает вопрос в профпригодности по этим трём пунктам.

Потому что отдельный /usr полезен как минимум:
a) при нештатных ситуациях (шанс повреждения большой ФС всегда больше при прочих равных);
b) для бездисковых станций (сейчас не всегда осмысленно делать тонких клиентов, но обслуживать десятки почти одинаковых машин индивидуально -- всё так же глупо и дорого).

Да, сейчас он менее актуален, чем десяток лет тому.  Но "выгода", которую пытаются впарить -- это маскировка бага под названием "макаронный дизайн", когда существенно различные части системы слишком много знают о потрохах друг друга и слишком на них завязаны.  Платить же за одёжку для уродства этими полутора процентами случаев, когда "ненужное" берёт и выручает -- продолжает видеться глупым.

Понимаете, я вот сейчас сижу и лопачу наслоения такого спагетти в mkimage-profiles-desktop, а некоторые и в делаемом mkimage-profiles остаются (размеченные # FIXME).  Оно просто раньше или позже выходит боком, любой программист со стажем подтвердит.

Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

283. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Moomintroll (ok) on 03-Ноя-11, 09:57 

> 1) в UNIX разработана и проверена практикой схема системных каталогов, имеющая много достоинств (в т.ч. в "редких" случаях и прочих нештатных ситуациях);

Это верно, однако, думаю, стоит вспомнить предпосылки, которые привели к существующей иерархии файловой системы... Когда-то давным-давно, когда деревья были выше, трава зеленее, а компьютеры "больше", операционная система UNIX распространялась на стримерных лентах и её установка была, в общем, нетривиальна. При этом, дисковая память (да и оперативная, но не о ней речь) была дорогая/дефицитная. Поэтому и использовалась "хитрая" схема с локальным корнем и /usr, смонтированным по NFS. Такая схема позволяла восстановить работоспособность сети (ибо в корне, да ещё и ro, ломаться, в общем, нечему, а проблемы с оборудованием из другой оперы), чтобы смонтировать /usr. Ну и дополнительно упрощалось обслуживание/сопровождение парка компьютеров за счёт единственной для каждой архитектуры копии /usr.


> a) при нештатных ситуациях (шанс повреждения большой ФС всегда больше при прочих равных);

В современном мире, по большому счёту, нет нужды любой ценой сохранять работоспособный корень, потому что больше не нужно загружать/устанавливать ОС со стриммерных лент. Ведь можно легко и непринуждённо загрузиться с Recovery CD/DVD/USB или даже из сети и починить всё, включая корень и сеть.

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

Тоже спорный вопрос. В современном мире существуют умные пакетные менеждеры, учитывающие множество факторов при установке пакетов, обёртки к этим пакетным менеджерам типа apt/yum/zypper/т.п., значительно облегчающие управление пакетами и ПО типа puppet, позволяющее управлять значительным количеством компьютеров с незначительными трудозатратами. А! Да! И дисковая память теперь дёшева. Соответсвенно, можно достаточно просто и успешно "обслуживать десятки почти одинаковых машин" но не "индивидуально", а "скопом".

Ну и, опять же, в некоторых случаях проще установить ОС заново, чем лечить поломанную (но это больше относится к Windows) - чай не со стримером мучиться.

Ответить | Правка | ^ к родителю #274 | Наверх | Cообщить модератору

287. "В Fedora рассматривается предложение по переносу всех исполн..."  –1 +/
Сообщение от perchibald (ok) on 03-Ноя-11, 13:54 
по мне UNIX схема достаточно деревянная... и на нее я ссылатся вообще не хочу... есть просто вещи которые необходимо модернизировать... я тоже не первый раз подрова хожу и по своему опыту могу сказать что мне на десктопе будет удобней что все исполняемые фалы будут лежать в одном месте))

ЗЫ. будь проще друг и к тебе потянутся)))

Ответить | Правка | ^ к родителю #274 | Наверх | Cообщить модератору

295. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Пр0х0жий (??) on 04-Ноя-11, 03:44 
> по мне UNIX схема достаточно деревянная...
> ...
> на десктопе будет удобней что все исполняемые фалы будут лежать
> в одном месте))

А потом в довесок каспера прикрутить.
Первая атака на iniramfs для отказа монтирования /usr и на первой перезагрузке ваша система в ауте. Модули ядра тоже. И bash прицепом туда же.

$ find /bin/ -name mount
/bin/mount

# find /lib/ -name modules
/lib/modules

Угу?
И тоже десктоп. Чем же FHS не угодила? Нет проблем? Скучно жить?

Ответить | Правка | ^ к родителю #287 | Наверх | Cообщить модератору

297. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от perchibald (??) on 05-Ноя-11, 12:24 
я тебя честно не очень понял... но поживем увидим
Ответить | Правка | ^ к родителю #295 | Наверх | Cообщить модератору

298. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Пр0х0жий (??) on 05-Ноя-11, 18:41 
> я тебя честно не очень понял...

Там очевидно. Если монтирование /usr, а оно будет идти из inird, сломается (или кто-то "сломает"), в аут уйдут kernel-modules которые будут лежать в несмонтированном /usr/lib, ну и bash туда же следом. Т.е. остаёмся и без ядерных модулей и без консоли. Графика в ауте как необсуждаемое.
Таким образом Леннарт /usr гайками к корню прикрутил и резьбу заварил, чтобы не откручивали. А это Виндовс-way. Отрывать /usr от корня при таком раскладе нельзя.
К тому же в некоторых дистрибутивах ради спокойной жизни /sbin, /usr/sbin принципиально оторвано из PATH даже у root, предполагая, что если лезет, то знает зачем. Леннарт же эти каталоги уже втиснул пользователю в PATH, что глупость несусветная, даже в глазах малоискушенного пользователя. Переводя на шутку: граната в определённых случаях штука полезная, но дают её не всем. Да и прячут её подальше не таская по прешпекту. Во избежание.
Пока пользователю терпеливо внедряли что всё держать в корне нехорошо и вроде бы приучили, мавр сделал своё дело.

Ответить | Правка | ^ к родителю #297 | Наверх | Cообщить модератору

300. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от perchibald (??) on 05-Ноя-11, 22:16 
а понял ты забезопасность кичишся... но видимо ленарт на селинукс оч расчитывает... а виндовс ваем тут и не пахнет по мойму и есть ли тако вообще)))... хотя безопасности ради возможно sbin лучше и сотавить
Ответить | Правка | ^ к родителю #298 | Наверх | Cообщить модератору

288. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 03-Ноя-11, 13:58 
Есть такая народная мудрость: "семь раз отмерь - один отрежь". Намного дальновиднее сначала подумать о последствиях, а уж затем делать. Но для некоторых (вас к ним, похоже, тоже можно отнести) главное - действие, остальное второстепенно.
Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

169. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от Аноним (??) on 02-Ноя-11, 10:10 
Существуют дистрибутивы, которые не могут загрузиться без initramfs и смонтированного до запуска /sbin/init /usr?
ППЦ. Они сами себе злобные буратины. Скоро, как гугль, для делания хоть чего-нибудь начнут требовать наличия подключения к интернету.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

173. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от Аноним (??) on 02-Ноя-11, 10:40 
Похоже разработчики федоры работают по принципу:
Ломай - чини @ без дела не сиди.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

182. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 02-Ноя-11, 11:56 
> Разработчики дистрибутива 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, а симлинки оставить для совместимости с программами, рассчитывающими на старое местоположение. ИМХО, симлинки в общем случае будут излишком (программы надо исправлять, а не каталоги симлинками захламлять), но общий курс как раз выглядит верным...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

183. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 11:57 
> Также упоминается то, что объединение sbin и bin вызовет необходимость действий со стороны разработчиков upstream-проектов.
> Файлы и каталоги, присутствие которых необходимо вне иерархии /usr предлагается связывать при помощи символических ссылок.

И какие такие действия необходимы со стороны разработчиков upstream-проектов?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

217. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от anonymous (??) on 02-Ноя-11, 15:56 
>И какие такие действия необходимы со стороны разработчиков upstream-проектов?

Очевидно, выпиливать отовсюду */sbin По лёгкому взмаху руки одного программного импотента.

Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

216. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 02-Ноя-11, 15:54 
> столько кирпичей, а из-за чего собственно? хорошее начинание

Если это начинание по выносу мусора из / в /usr, как написано на FreeDesktop.org, то это хорошо.

Если же это начинание по сливанию всего в одну кучу, как это звучит в тексте новости, то с таким хорошим начинанием плохих не надо.

Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

238. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 02-Ноя-11, 17:16 
> Разработчик сказал "я делаю А", некий лох на сайте разместил новость "разработчик
> делает Б". Кому верить? Я, как и вы, в полном неудоумении...

Лох не лох, но вброс в любом случае вышел знатный. :)))

Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

246. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 18:37 
> Разработчик сказал "я делаю А", некий лох на сайте разместил новость "разработчик
> делает Б". Кому верить? Я, как и вы, в полном неудоумении...

В новости как раз всё верно сказано, в 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 это и есть сваливание в кучу.

Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

221. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 02-Ноя-11, 16:18 
Вот эта идея именно то, что и называют "от глюкавого!"...

У меня даже нет слов! Бред, полнейший. С таки же успехом можно DNS обратно превращать в "плоскую" систему имен.

Иерархия нужна однозначно. Уж хотя бы для безопасности. Потом есть еще такая вещь как скорость обработки запросов - иерархичные системы почему то куда быстрее в поисковых запросах. А раздельные каталоги преследует именно эту цель: не класть яйца в одну корзину.

То что эта идея полный п...ц, я заявляю именно как линуксовый сисадмин. Сертифицированный, кста (если кому это интересно).

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

289. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 03-Ноя-11, 16:47 
В принципе этот дистрибутив не относится к классу стандартов, это так называемый development tools и таким останется - так что делать можно все что хочется
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

299. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от anonymous (??) on 05-Ноя-11, 19:44 
>В принципе этот дистрибутив не относится к классу стандартов, это так называемый development tools и таким останется - так что делать можно все что хочется

Не забывай про /run Где он первым появился? А уж про такие вещи как systemd, pulseaudio, netrworkmanager я скромно промолчу.

Ответить | Правка | ^ к родителю #289 | Наверх | Cообщить модератору

293. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от жора on 03-Ноя-11, 23:37 
> В настоящее время дистрибутив нереально загрузить без /usr
> (/usr монтируется из initramfs до запуска процесса инициализации и
> содержит необходимые для загрузки компоненты)

Если и в самом деле додумались до этой глупости (все-таки думаю, что это гипербола),
то ее и надо чинить, вместо того, чтобы учудить еще одну.

Умиляет довод, что /usr можно будет монтировать на разных машинах.
Это как раз сейчас и можно, поскольку и без /usr система работоспособна и может
обеспечить такое монтирование (или они из initramfs хотят /usr монтировать, делая машину
полностью неработоспособной при сбое сети).

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

301. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Андрей (??) on 06-Ноя-11, 04:15 
> а также то, что в sbin можно найти программы, которыми пользуются и обычные пользователи.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

303. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (??) on 09-Ноя-11, 16:59 
Вот это инновация!
А почему бы вообще все файлы не скидать в одну папку?
Ууу, какие перспективы открываются...
Зачем вообще тогда эта стандартная структура папок создавалась?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру