Обязательные для выполнения:
Желательные для выполнения:
В список желательных модулей для alterator:
первое – да. Наверное стоит просто добавить эту фичу в какой-то из модулей настройки (например оборудование).
Второе.. наверное простому пользователю это не нужно, а эксперт наверное и сам сможет сделать ?
Или нужно простому пользователю ?
А зачем ?
Первое — а что за модуль такой настройки «оборудование»? Я что-то пропустил?
Второе — у простого пользователя может возникнуть проблема из-за того, что hotplug что-то
настраивает, чего не надо. Если будет простое средство отключить и проверить — пользователь
легко сможет локализовать, что проблема именно в hotplug (или, наоборот, где-то в другом месте).
Какое облегчение для поддержки и какие возможности для массового тестирования hotplug!
Вообще, чем прозрачнее будет система hotplug/udev, тем меньше будет недовольства ею и со
стороны разработчиков, и со стороны пользователей. А, наоборот, будет довольство (удобно же,
когда делают за тебя ровно то, что ты сам не хочешь делать — но не больше!).
Да, в TODO в обязательных изменениях есть
я расшифровал немного, добавил про настройку автомонтирования
по поводу hotplug'а – если речь идет о загрузке модулей при старте, то собственно в TODO есть пункт:
«перенос детекта оборудования из hotplug в отдельный сервис (например hardware)"
подразумевается под этим как раз переработанный детект железа и загрузка соответствующих ему драйверов. т.е. – всё должно стать более прозрачно и понятно. управляться все это будет через конфигурационные файлы libhw (как и задумывалось). Отключать загрузку драйверов в теории можно, но на практике.. непонятно.
В общем и целом это всё должно настраиваться через монстроподобный модуль управления оборудованием.
если ты уверен что xorg 7.0, то давай поменяем. правда для того, что бы всё было хорошо – надо уже начинать готовить базовую систему. Т.е. – что бы где-то к январю у нас уже всё срослось по базовой системе и мы смогли начать её тестирование
вру.. к концу января, естественно ;-)
релиз обещают в декабре.
Я бы настройку оборудования не засовывал всю в один модуль, хотя это скорее дело вкуса.
Что же касается hotplug, то главное, что в нём хотелось бы разделить — это определение оборудования и загрузку драйверов.
Пусть одна часть hotplugа определила оборудование — и записала куда-нибудь в читабельной форме: есть такое-то и такое-то,
драйверы, я считаю, нужны такие-то и такие то. Эту невинную часть хотплага и отключать-то никогда не потребуется.
А другая часть hotplugа пусть уже загружает драйверы, но _только те_, которые ей разрешено загрузить в ей конфиге.
Вот к этому-то конфигу второй части с разрешениями грузить драйверы и нужен простой интерфейс в виде модуля к альтератору.
Потому что отключать всю вторую часть жалко и, наверное, никогда не нужно. А вот отключать загрузку _некоторых_ драйверов может быть нужно очень.
ё
в это общедоступное место — и
Пусть он определяет всегда, это и отключать не нужно. Но чтобы загрузка
Давай начнем с того, что забудем про hotplug.
Будем говорить про сервис hardware и libhw
Итак, смотрим что у нас получается:
– сервис детекта оборудования и генерации конфига
– сервис загрузки модулей согласно этому конфигу
я это объединяю в один сервис – детект и загрузка. два дополнительных в этом случае не нужно. Просто процесс детекта делаем управляемым и настраиваемым. Например так, что бы через конфиг можно было отключить какой-то драйвер или сменить.
Т.е. – реально будет конфиг, управляющий выводом команды pciscan -r, через который собственно и идет загрузка драйверов.
В принципе это есть уже сейчас, но без конфигуратора – никто не знает как им пользоваться.
ну тогда оставим под вопросом... собственно нам я так понимаю не суть важно иметь 7.0 а не 6.9. По качеству они примерно одинаковы ?
да, это одно и то же. 6.9 монолитный, 7.0 модульный. вот и все отличие
Хм.. а release candidate 2 не хочешь собрать в пакеты (я про xorg-7.0) ?
Наверняка самый гемморой будет с первой сборкой, дальше уже будет намного легче.
можно попробовать, хотя щас времени на это нет. я все таки планировал этим заняться после релиза
Я прошу прощения, но в моем представлении характеристики «упрощенный» и с «интеллектом» находятся в противоречии. Поэтому хотелось бы узнать, каким, все-таки, должен быть модуль настройки загружчика? :)
Также прошу расшифровать:
«модуль автоматической установки системы».
Не потому, что непонятно, а потому, что этой задачей можно заниматься до бесконечности. Границы интересны.
Куда-нибудь нужно дописать доработку интерфейса инсталлятора и конфигуратора. В частности, чтобы пользователь видел привычные песочные часы во время длительных задержек.
Но это лишь один из множества примеров.
Модуль установки загрузчика должен быть интеллектуальным с упрощённым интерфейсом для пользователя (то же самое что есть сейчас в 3.0).
Модуль автоматической установки системы – возможность проводить стандартные установки по сценарию.
Про интерфейсы понятно.
Игорь просил при разработке интерфейса управления оборудованием подумать о кнопке «сохранить сведения о системной конфигурации», что позволило бы пользователям быстро и без проблем собрать всю необходимую для обращения в техподдержку информацию об их системе.
Powered by WackoWiki R4.2