[devel] Re: Два подхода к жизни или как делать по дефолту

Пн Ноя 29 19:15:21 MSK 2004

Вот что называется кратко и конструктивно !!!!!!!!!

;-)

2gvy: не обижайся, но я твой полет мысли читать не стал.. очень долго, 
мало времени, много ненужной воды. Практически никакой конкретики.

Michael Shigorin wrote:

>On Mon, Nov 29, 2004 at 04:41:24PM +0300, Anton Farygin wrote:
>  
>
>>Возник такой у нас с Pilot'ом интересный спорный вопрос.
>>Просьба конструктивно и _кратко_ на него ответить:
>>на ваш взгляд: сразу после установки системы после первой
>>загрузки должны ли быть видны доступные в системе сетевые
>>интерфейсы по команде ifconfig -a _до этапа настройки  сети
>>(через конфигуратор) пользователем_ ?
>>Можно просто сказать: да/нет.
>>    
>>
>
>1) да, это неважно;
>2) нет, это неважно. :)
>
>IMCO это был неверный вопрос, любой ответ на который ровным
>счётом ничего не значит.
>
>Попробую по возможности объективно осветить проблему; в конце
>прилагается также чуточку пофильтрованный по релевантности лог.
>
>
>Вопрос
>~~~~~~
>Где и как определяется точная программная конфигурация
>аппаратного обеспечения (по умолчанию и специфическая)?
>
>
>Обсуждение
>~~~~~~~~~~
>Существует два "полярных" варианта -- "всё настроено
>автоматически" и "всё настраивается руками".
>
>Первое -- это Plug'n'Play и на Linux в данный момент -- hotplug.
>(в сторону: а есть ли hotplay? :)
>
>Второе -- это $EDITOR и сокровенное знание, что и где именно
>править помимо знания значений, которые в конфигурацию должны
>попасть.
>
>Вменяемые системы находятся где-то посредине -- дают возможность
>реализовать промежуточные варианты, от минимального вмешательства
>(например, указание значения конфигурации) до минимальной
>автоматизации (например, загрузка модуля, соответствующего
>заданному PCI-устройству).
>
>При этом у нас есть несколько типичных точек, приводящих к
>изменениям состояния этой конфигурации:
>
>1) первичная установка и настройка операционной среды
>   (в данный момент -- mdk installer, в перспективе это
>   обеспечивается alterator);
>
>2) настройка добавленного в процессе эксплуатации системы
>   оборудования;
>
>3) ручное изменение конфигурации администратором системы.
>
>При этом каждый из этих пунктов состоит из некоторой
>автоматической настройки (с использованием значений или
>соответствий по умолчанию) и некоторой ручной деятельности
>(как минимум согласие, обычно инициирование, подчас -- ввод
>значений, которые не могут быть определены автоматически).
>
>Как правило, случаи с одним устройством заданного класса не
>приводят к проблемам, т.к. система не предоставляет выбора по
>причине его объективного отсутствия (разве что "отключить вообще"
>как альтернатива "чтоб работало").  Проблемы начинаются с
>"размножением" устройств одного класса и невозможностью
>автоматически определить соображения владельца аппаратного
>обеспечения по части того, как именно оно должно работать.
>
>
>Соображения
>~~~~~~~~~~~
>В идеале система не должна _требовать_ что-либо настраивать
>вручную, но если администратор усматривает в этом необходимость
>-- надо предоставить средства внесения и учёта изменений
>(хороший пример -- control(8)).
>
>Для звуковых чипов _частичным_ (ALSA-only) решением является
>использование параметра модуля "index" (см. ссылки); для сетевых
>интерфейсов -- nameif/ifrename (насколько понимаю).
>
>Для драйверов другого аппаратного обечпечения такие регуляторы
>могут как наличествовать, так и отсутствовать; при этом общая
>проблема в каждом конкретном случае решается разными средствами
>(отчасти? из-за разных источников идентификационной ниформации).
>
>
>Пример
>~~~~~~
>Рассмотрим два класса аппаратного обеспечения, которые уже
>создают проблемы на пару с hotplug в случае попытки управлять ими
>с его помощью -- сетевые интерфейсы и звуковые платы.
>
>В обоих случаях точное соответствие логических и физических
>устройств обычно критично и не должно зависеть от изменений
>порядка сканирования PCI-шины ядром или иной погоды на Марсе:
>изменение порядка логических устройств приводит к тому, что
>сигнал подаётся не на тот разъём, где его ждут.
>
>В случае сетевого интерфейса это может привести к "странным"
>(плохо описываемым и решаемым поддержкой) проблемам в сочетании с
>файрволами, ограничением доступа по MAC и т.д.; в случае
>звуковой платы -- в лучшем случае к тому, что для воспроизведения
>будет использоваться низкокачественное устройство вместо
>высококачественного (и то лишь после манипуляций с проводами), в
>худшем же проснувшийся в три часа ночи стояк может надолго лишить
>майнтейнера способности заниматься пакетами что в наушниках, что
>без них.
>
>При этом для сетевых интерфейсов ситуация усложняется тем, что
>довольно распространено применение однотипных сетевых карт,
>которые работают на одном драйвере (стоит учитывать в п.2).
>
>Возможно, встроенные звуковые карты "в среднем" получают более
>низкие идентификаторы на шине и склонны становиться первым
>логическим устройством в системе, которое по умолчанию и будут
>использовать программы, выводящие звук -- характер жалоб сводится
>к "играет через встроенную, а не нормальную".
>
>Выводы
>~~~~~~
>Основная проблема, которая может возникнуть -- не техническая:
>учёт мнения человека.  Обычно её решают созданием конфигураторов.
>
>В отличие от rider@ мы с pilot@ считаем, что человеку, который
>настраивает систему без конфигуратора, лишний modprobe не будет
>проблемой (если он делает это N-й раз -- значит, это можно
>автоматизировать на этапе создания иных настроек по умолчанию для
>заданного случая -- например, livecd первой стадии нового
>инсталятора).
>
>При этом есть мнение, что решение частной проблемы разработчика
>(загрузка всех соответствующих обнаруженному, в т.ч. сетевому
>железу модулей) слишком общими средствами (возврат к такому
>поведению по умолчанию) затруднит тестирование подсистемы,
>которой оно также требуется (etcnet) в силу банального роста
>прикладных неудобств для администраторов, которые и так должны
>быть чем-то мотивированы, чтобы её тестировать, да ещё и на
>ядре 2.6.  Попросту говоря, перетыкание кабелей это тестирование
>сведёт к нулю.
>
>Ссылки
>~~~~~~
>Предыдущее обсуждение вопроса (включая отношение пользователей к
>излишней жёсткости системы по части соответствия):
>
>http://lists.altlinux.ru/pipermail/sisyphus/2004-June/041781.html
>http://lists.altlinux.ru/pipermail/community/2003-September/098147.html
>http://lists.altlinux.ru/pipermail/sisyphus/2004-May/041698.html
>https://bugzilla.altlinux.org/show_bug.cgi?id=4668
>https://bugzilla.altlinux.org/show_bug.cgi?id=3487
>https://bugzilla.altlinux.org/show_bug.cgi?id=3528
>https://bugzilla.altlinux.org/show_bug.cgi?id=1802
>
>Приложение
>~~~~~~~~~~
><Pilot> rider: ну так что, ifconfig-то не спасёт
><rider> gvy: ничего ты не понял ;-)
>* Pilot тоже ничего не понял
><gvy> rider, а конфигуратор сети планируется дёргать из
>инсталятора?
><Pilot> тогда так, господа
><rider> gvy: нет конечно. А зачем ?
><gvy> бишь поставили базовую систему, бутнулись в неё, что
>дальше?
><gvy> как зачем?
><Pilot> нужна гуйня для конфигурации сети, выходит
><rider> Pilot: да. Гуйня нужна. Но это - не дело инсталятора
>настраивать сеть.
><Pilot> кто будет её писать?
><gvy> Pilot, это дело команды alterator
><rider> Pilot: ну кроме нас некому
><Pilot> rider: если будет, то в чём проблема и зачем размахивать
>ifconfig?
><rider> Pilot: но прежде чем писать гуйню - нужно закончить
>баталии. Нужно определиться кто как и что будет
>грузить/настраивать
><Pilot> я думал, всё уже давно определилось
><rider> Pilot: да в том, что нет у меня гуйни. Я после загрузки
>хочу быстро получить доступ в сеть. Что может быть быстрее
>ifconfig ?
><Pilot> rider: тебе 25-го нужо было приезжать в офис
><rider> Pilot: да нет. Не определилось. В том то и дело.
><Pilot> rider: хозяин-бырин
><Pilot> барин
><rider> Pilot: что будет если я сейчас включу в hotplug'е
>загрузку драйверов для сети ? много сломается ?
><Pilot> rider: я не о тебе, а о других пользователях
>	[skip]
><rider> Pilot: не нужна - идем в /etc/libhw.conf и отключаем
>драйвер для конкретного сетевого устройства
><Pilot> rider: давай спросим общественного мнения, я уже доводы
>исчерпал, хотя мнения не изменил
><rider> Pilot: вот тебе другой пример: новичок поставил
>дистрибутив, загрузился и ему говорят о том, что бы настроить
>сеть нужно сменить IP адрес на интерфейсе (стандартный подход
>практически в любом UNIX).
>* lioka думает, что автосеть должна быть в отдельном пакете, не
>являющемся неотъемлемой частью сетевой подсистемы.
><Pilot> ну и что?
><lioka> если вы об этом
><rider> lioka: нет. До автосети мы еще доберемся ;-)
><Pilot> не сменить, а назначить
><rider> Pilot: хорошо. Назначить.
><Pilot> и пусть себе назначает
><Pilot> я ж не мешаю
><rider> Pilot: да как он назначит, если: ifconfig eth0 его
>посылает, ибо 1) модуль не загружен 2) в /etc/modules.conf alias
>отсуствует
><Pilot> о!
><gvy> rider, новичка пошлёт уже отсутствие конфигуратора :(
>* gvy не выдержал попытки решения проблемы на НЕ ТОМ уровне
><rider> gvy: помолчи, ПОЖАЛУЙСТА!
><Pilot> для этого один абзац жалко, что ли? написать, что такое
>lspcidrake и что такое modprobe
><rider> Pilot: а зачем ?
><rider> Pilot: когда можно все сделать автоматически
><Pilot> вместо того, чтобы зашоривать, подсказать ему нормальный
>путь конфигурации оборудования, если инстяллятор не постарался
><rider> Pilot: и плюс к этому _безусловно_ - нормальный путь
>конфигурации
><Pilot> rider: ты придумываешь какой-то холодный ядерный синтез
>для чайников за 5 минут
><Pilot> давайте или по-простому или по-пацански
><rider> Pilot: понимаешь, если бы во всех Linux'ах настройка
>аппаратной части была одинакова - я бы с тобой согласился
><rider> Pilot: а так - я не согласен. Проведем блиц-опрос в
>devel@
><rider> Pilot: нет, мы говорим о пользователях, которые
>пользуются системой.
><Pilot> как там в RH, мне по барабану, я хочу сделать лучше
><Pilot> rider: проведём. только мои комментарии тоже должны быть
>в опросе
><rider> Pilot: я написал уже письмо - посмотри
><rider> Pilot: я задал вопрос просто: на ваш взгляд: сразу после
>установки системы после первой загрузки
><rider> должны ли быть видны доступные в системе сетевые
>интерфейсы по команде
><rider> ifconfig -a _до этапа настройки  сети (через
>конфигуратор) пользователем_ ?
>* Pilot . o O (без меня меня женили, развели и посадили)
><rider> Pilot: вообще речь идет не только о тебе
>	[pause]
><rider> gvy: ну да. Но опять же - это же не вопрос sound-scripts.
>Просто hotplug будет работать так же как и всегда - спокойно
>грузить драйвера. А sound.agent - менять индекс, если это надо.
><gvy> rider, ыыы... в смысле менять индекс?
><gvy> после загрузки модуля этот индекс до фени
><Pilot> rider: наконец-то ты озвучил идею!
><gvy> rider, давай я в devel попробую схему проблемы очертить?
><rider> gvy: ага. тогда этим будет заниматься конфигуратор,
>настраивающий libhw
><gvy> ВОООТ!
><Pilot> raorn: достаточно, если eth1 есть
><gvy> rider, именно это я уже час и пытаюсь сказать -- железо
>(драйверы) без конфигурации никому не нужны, кроме нас,
>разработчиков :)
><gvy> а мы можем дефолт данной конкретной сборки под себя
>подогнать
><rider> gvy: не всегда. В большинстве случаев дефолтные
>конфигурации срабатывают
><gvy> rider, в большинстве -- да.
><Pilot> rider: я подумаю, как предметно ответить на разделение
><gvy> по крайней мере хорошие дефолтные конфигурации
><rider> Pilot: ok.
><rider> gvy: ну да. а все остальное - действительно дело рук
>конфигуратора.
>
>PS: меня опять отвлекли где-то в районе перехода к примерам. :E
>
>  
>