The OpenNET Project / Index page

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



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

Оглавление

Обоснование целесообразности переноса компонентов из корня в..., opennews (ok), 27-Янв-12, (0) [смотреть все] –1

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


187. "Обоснование целесообразности переноса компонентов из корня в..."  +2 +/
Сообщение от Аноним (-), 27-Янв-12, 21:10 
> Минус этого переноса очевиден. Рушится базовая система, необходимая для административных действий в случае проблем с загрузкой.

Каких именно проблем? Если у тебя система не загрузилась с бинарниками в /usr/bin то с чего ты решил, что она магическим образом загрузится с бинарниками в /bin ?

> Во-первых не факт, что все дистрибутивы и юникс системы последуют призыву Портинга
> в светлое будущее. Во-вторых, даже если так произойдет, желаемой унификации не
> будет по причене разного подхода к расположению и содержанию конфигов. К
> примеру один и тот же сетевой /usr монтируется на станциях разными
> дистрибутивами. В одном конфиги в /etc/program, в другом в /etc/program.conf.

Унификация означает "одинаковые принципы построения", а вовсе не "одинаковые имена каждого файла".

> Вот здесь все наоборот. Кроме /usr придется монтировать как минумум /etc.
> Сейчас же, например, в ltsp, монтируется только один корень или по nfs
> ro или, что чаще, nbd + squashfs и накладывается на фс
> в оперативной памяти. Это и функциональнее, и совершеннее, и не менее
> безопасно.

Неверно. Конфиги и другие файлы, специфичные для машины хранятся на самой машине. Монтировать некий общий /etc просто нет необходимости. Так что единый /usr в ro  безопаснее и удобнее

> Приехали. Обновили /usr1. При этом изменился /etc. Вернулись на /usr0. И "великий"
> systemd, прочитав конфиг, пытается грузить не существующие программы. Возможно, systemd
> будет хранить конфиги в другом месте, но проблема не сильно меняется.

Если обновление затрагивает /etc (причём именно ломающим совместимость образом) - ничто не мешает сделать его снэпшот.

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

Забавно: необходимость монтировать несколько разделов в случае с ltsp позиционируется как недостаток, а теперь - как достоинство. Ты уж определись - гибкость это или гемор?

> Доводы передового разработчика напоминают отписку для дураков. Думаю, большинство дистрибутивов в этом вопросе не пойдут стройными рядами за Федорой.

До сих пор шли: /run во всех дистрибутивах уже есть или в ближайших планах, pulseaudio - тоже.
Может быть всё дело в том, что аргументы Поттеринга рассчитаны на тех, кто постоянно занят развитием и поддержанием дистрибутивов, а не досужими рассуждениями на форумах?


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

190. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от жора (?), 27-Янв-12, 21:21 
Ты прочитать пробовал, на что отвечаешь?

> Каких именно проблем? Если у тебя система не загрузилась с бинарниками в
> /usr/bin то с чего ты решил, что она магическим образом загрузится
> с бинарниками в /bin ?

О том и речь. Могут быть проблемы с монтированием /usr. Особенно сетевого.

>> Во-первых не факт, что все дистрибутивы и юникс системы последуют призыву Портинга
>> в светлое будущее. Во-вторых, даже если так произойдет, желаемой унификации не
>> будет по причене разного подхода к расположению и содержанию конфигов. К
>> примеру один и тот же сетевой /usr монтируется на станциях разными
>> дистрибутивами. В одном конфиги в /etc/program, в другом в /etc/program.conf.
> Унификация означает "одинаковые принципы построения", а вовсе не "одинаковые имена каждого
> файла".

К зоопарку добавлен еще один "принцип построения". Или вы уверены, что все остальные "исчезнут".

>> Вот здесь все наоборот. Кроме /usr придется монтировать как минумум /etc.
>> Сейчас же, например, в ltsp, монтируется только один корень или по nfs
>> ro или, что чаще, nbd + squashfs и накладывается на фс
>> в оперативной памяти. Это и функциональнее, и совершеннее, и не менее
>> безопасно.
> Неверно. Конфиги и другие файлы, специфичные для машины хранятся на самой машине.
> Монтировать некий общий /etc просто нет необходимости. Так что единый /usr
> в ro  безопаснее и удобнее

Речь шла бездисковых станциях.

>> Приехали. Обновили /usr1. При этом изменился /etc. Вернулись на /usr0. И "великий"
>> systemd, прочитав конфиг, пытается грузить не существующие программы. Возможно, systemd
>> будет хранить конфиги в другом месте, но проблема не сильно меняется.
> Если обновление затрагивает /etc (причём именно ломающим совместимость образом) - ничто
> не мешает сделать его снэпшот.

Да. только ради чего?

>> /usr и сейчас можно монтировать только для чтения. Но, кроме этого /bin
>> можно монтировать, а можно использовать и свой оригинальный, что дает дополнительную
>> гибкость.
> Забавно: необходимость монтировать несколько разделов в случае с ltsp позиционируется
> как недостаток, а теперь - как достоинство. Ты уж определись -
> гибкость это или гемор?

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

>> Доводы передового разработчика напоминают отписку для дураков. Думаю, большинство дистрибутивов в этом вопросе не пойдут стройными рядами за Федорой.
> До сих пор шли: /run во всех дистрибутивах уже есть или в
> ближайших планах, pulseaudio - тоже.
> Может быть всё дело в том, что аргументы Поттеринга рассчитаны на тех,
> кто постоянно занят развитием и поддержанием дистрибутивов, а не досужими рассуждениями
> на форумах?

Почитайте мнение этих людей. Они, мягко говоря, далеко не однозначны.

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

197. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Аноним (-), 27-Янв-12, 21:45 
> О том и речь. Могут быть проблемы с монтированием /usr. Особенно сетевого.

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

> К зоопарку добавлен еще один "принцип построения". Или вы уверены, что все
> остальные "исчезнут".

Он добавлен ещё лет 15 назад в эпоху классического юникса. Что там говорил про "читать на что отвечаешь"? ;)

> Речь шла бездисковых станциях.

Тогда твоя фраза "монтируется поверх" лишена всякого смысла - поверх чего может монтироваться сетевой раздел на _бездисковом_ терминале?

> Да. только ради чего?

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

> Почитайте мнение этих людей. Они, мягко говоря, далеко не однозначны.

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

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

203. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от жора (?), 27-Янв-12, 22:10 
> Могут разумеется - только маловероятно, что загрузка в / поможет эти проблемы
> решить. Нет, конечно такой маленький шанс есть, при условии что загрузка
> без /usr работает - в большинстве современных дистрибутивов это не так
> - несмотря на формальное разделение этот use-case как правило не тестируется.

На большинстве - это на Федоре. В однопользовательском режиме все же обычно не используется /usr.

> Он добавлен ещё лет 15 назад в эпоху классического юникса. Что там
> говорил про "читать на что отвечаешь"? ;)

Я о ссылках /bin -> /usr/bin и т.д.


>> Речь шла бездисковых станциях.
> Тогда твоя фраза "монтируется поверх" лишена всякого смысла - поверх чего может
> монтироваться сетевой раздел на _бездисковом_ терминале?

Сетевой корень cовмещается с корнем в оперативке.

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

Точно так же, как и сейчас.

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

211. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (-), 27-Янв-12, 22:31 
> На большинстве - это на Федоре. В однопользовательском режиме все же обычно
> не используется /usr.

cd /sbin && ldd *|grep /usr | wc -l
На моей убунте даёт 47.
Можешь проверить на своём любимом дистре.
Надо что-то ещё пояснять про "обычно не используется /usr"?

> Я о ссылках /bin -> /usr/bin и т.д.

Можешь посмотреть на соплярис, от 11 и выше.

> Сетевой корень cовмещается с корнем в оперативке.

Внимание вопрос: откуда этот самый корень взялся в оперативке на _бездисковой_ станции?

>> А почему бы и нет собственно? Это всего лишь один из множества
>> плюсов от предлагаемых улучшений. Сейчас такое сделать крайне геморройно, после объединения
>> /usr это сделать будет легко.
> Точно так же, как и сейчас.

Ты не понимаешь разницы или притворяешься?
Для понимания можешь попробовать посмотреть через какие костыли это реализовано в calculate linux. Потом сравнить с парой командой mount, которые потребуются для реализации того же после того как предложения Сиверса со товарищи станут стандартом.

А я уверен, что они станут - просто потому, что это удобнее и облегчает портирование софта.

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

219. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от жора (?), 27-Янв-12, 23:28 
> cd /sbin && ldd *|grep /usr | wc -l
> На моей убунте даёт 47.
> Можешь проверить на своём любимом дистре.
> Надо что-то ещё пояснять про "обычно не используется /usr"?

У меня на дом. дебиане три библиотеки. Причем некритичные (ntfs, ntfs-3g, fuse).
Тем не менее этот довод (Все украдено до нас) все же весомее пустословия Потеринга.

> Можешь посмотреть на соплярис, от 11 и выше.

Исходная тема - унификация. А тут умирающий Солярис.

> Внимание вопрос: откуда этот самый корень взялся в оперативке на _бездисковой_ станции?

Корня в памяти не встечал? Или он только на дисковых станциях возможен?
Тем не менее вопрос к теме не относится.

> Ты не понимаешь разницы или притворяешься?
> Для понимания можешь попробовать посмотреть через какие костыли это реализовано в calculate
> linux. Потом сравнить с парой командой mount, которые потребуются для реализации
> того же после того как предложения Сиверса со товарищи станут стандартом.

Тем не менее не вижу принципиальной разницы.

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

221. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Аноним (-), 27-Янв-12, 23:38 
> У меня на дом. дебиане три библиотеки. Причем некритичные (ntfs, ntfs-3g, fuse).
> Тем не менее этот довод (Все украдено до нас) все же весомее
> пустословия Потеринга.

Вообще-то этот аргумент я как раз у Поттеринга и взял. Ты б всё же прочитал оригинальную статью, а?

>> Можешь посмотреть на соплярис, от 11 и выше.
> Исходная тема - унификация. А тут умирающий Солярис.

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

>> Ты не понимаешь разницы или притворяешься?
>> Для понимания можешь попробовать посмотреть через какие костыли это реализовано в calculate
>> linux. Потом сравнить с парой командой mount, которые потребуются для реализации
>> того же после того как предложения Сиверса со товарищи станут стандартом.
> Тем не менее не вижу принципиальной разницы.

Ну спроси у разработчиков calculate linux - они тебе объяснят сколько заняла разработка данной фичи и сколько усилий требуется на её поддержку.

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

289. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Клыкастый2 (?), 28-Янв-12, 23:30 
> Для понимания можешь попробовать посмотреть через какие костыли это реализовано в calculate linux.

можно подробностей?

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

302. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от mihail krijich (?), 29-Янв-12, 08:13 
>> На большинстве - это на Федоре. В однопользовательском режиме все же обычно
>> не используется /usr.
> cd /sbin && ldd *|grep /usr | wc -l
> На моей убунте даёт 47.
> Можешь проверить на своём любимом дистре.
> Надо что-то ещё пояснять про "обычно не используется /usr"?

вот это, в первую очередь, и нужно чинить, а не дальше ломать.

# uname -a
FreeBSD myhost 8.2-RELEASE-p6 FreeBSD 8.2-RELEASE-p6 #1: Tue Jan 10 14:21:54 MSK 2012     root@myhost:/usr/obj/usr/src/sys/MYKERNEL  amd64
# cd /sbin && ldd *|grep /usr | wc -l
       0
# cd /bin && ldd * | grep /usr | wc -l
       0

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

305. "Обоснование целесообразности переноса компонентов из корня в..."  –1 +/
Сообщение от Аноним (-), 29-Янв-12, 12:29 
> вот это, в первую очередь, и нужно чинить, а не дальше ломать.

А где ты увидел предложение сломать что-либо?
Опять пытаешься выдать свой бред за реальность?

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

310. "Обоснование целесообразности переноса компонентов из корня в..."  +1 +/
Сообщение от mihail krijich (?), 29-Янв-12, 16:00 
>> вот это, в первую очередь, и нужно чинить, а не дальше ломать.
> А где ты увидел предложение сломать что-либо?
> Опять пытаешься выдать свой бред за реальность?

Перестань паясничать, лукавить и подлизывать. Понимаю, не приятно за фидору, но увы...

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

284. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от netch (ok), 28-Янв-12, 22:09 
>> Могут разумеется - только маловероятно, что загрузка в / поможет эти проблемы
>> решить. Нет, конечно такой маленький шанс есть, при условии что загрузка
>> без /usr работает - в большинстве современных дистрибутивов это не так
>> - несмотря на формальное разделение этот use-case как правило не тестируется.
> На большинстве - это на Федоре. В однопользовательском режиме все же обычно
> не используется /usr.

Боюсь, ты таки с фряхой попутал. Там действительно в single user автоматом только корень.
В большинстве линуксов при этом уже смонтировано всё автоматически подключаемое, под руководством /etc/rc.sysinit или аналога.


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

290. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Клыкастый2 (?), 28-Янв-12, 23:31 
> Боюсь, ты таки с фряхой попутал. Там действительно в single user автоматом только корень.

хм. а это чем-то плохо?

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

327. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от netch (ok), 30-Янв-12, 13:57 
>> Боюсь, ты таки с фряхой попутал. Там действительно в single user автоматом только корень.
> хм. а это чем-то плохо?

Для неё - нет. Потому что в корне достаточно средств, чтобы попасть в шелл, сделать mount, fsck, загрузить штатные модули, отредактировать fstab (через /bin/ed) и в общем выполнить весьма немалый объём всякой возни. И они проверяются на работоспособность.

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

333. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от mihail krijich (?), 30-Янв-12, 14:31 
>(через /bin/ed)

ed - конечно сильно, но можно и более обыденными средствами: /rescue/vi

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

334. "Обоснование целесообразности переноса компонентов из корня в..."  +/
Сообщение от Michael Shigorinemail (ok), 30-Янв-12, 14:46 
>> Может быть всё дело в том, что аргументы Поттеринга рассчитаны на тех,
>> кто постоянно занят развитием и поддержанием дистрибутивов, а не досужими
>> рассуждениями на форумах?

Вы с ними хоть общались, крикливый Вы наш?

> Почитайте мнение этих людей. Они, мягко говоря, далеко не однозначны.

Вот именно.

Спасибо за изложенное, хотя читать и воспринимать Вашему оппоненту, похоже, сложно. :(

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

260. "Обоснование целесообразности переноса компонентов из..."  +1 +/
Сообщение от arisu (ok), 28-Янв-12, 12:03 
> До сих пор шли: /run во всех дистрибутивах уже есть или в
> ближайших планах, pulseaudio — тоже.

(внимательно осмотрел свою слаку) нету. вы, сударь, лжец.

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

261. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от Аноним (-), 28-Янв-12, 12:48 
Речь шла о дистрибутивах, а не о детских конструкторах.
Ответить | Правка | Наверх | Cообщить модератору

263. "Обоснование целесообразности переноса компонентов из..."  +/
Сообщение от arisu (ok), 28-Янв-12, 12:52 
> Речь шла о дистрибутивах, а не о детских конструкторах.

это, случайно, не о тех, у которых несколько лет мегабаг в OpenSSL был, потому что маинтайнер — криворукий идиот? благодарю, я лучше на «детском конструкторе» останусь.

p.s. то, что ты слаку видел только издалека в виде iso-образа — даже доказывать не надо.

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

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

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




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

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