The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В Fedora рассматривается предложение по переносу всех исполн..., opennews (ok), 01-Ноя-11, (0) [смотреть все]

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Давайте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[...]

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

277. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorinemail (ok), 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'нуть, но это ж тоже понимать надо...

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

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

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

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

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

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

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

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

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

шляпы нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

269. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от csdoc (ok), 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.

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

278. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorinemail (ok), 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.

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

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

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

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

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

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

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




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

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