Что придёт на смену xorg.conf?

А ты как хотел? Вот сделают реестр - что-то в нём сломается - и кирдык. Переустановишь систему/запустишь создание всей конфигурации с нуля.

Я вот что не могу понять - ну, будет реестр. Там красивое дерево с данными. Сейчас я вижу две мотивации - в /etc каша и куча конфигов, и вторая - давайте не будем изобретать велосипед.

Так вот, п1: сейчас есть то же самое дерево с данными, его корень - в /etc, там можно задавать кучу разных прав всем узлам. Интерпретация данных так же зависит от приложения. п2: Изобретать велосипед и не нужно, никто не мешает взять уже написанный парсер (YAML, libconfig,...).

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

с gconf - они там вообще обалдели?

А в чём проблема? Я только за. Текст для конфигов - не лучший формат, формат дерева на порядки удобнее и читабельнее.

в том и проблема. вам удобнее "что-то еще 1", другому "что-то еще 2" а plaintext- медиана. корявый, но [более-менее]паллиатив, устраивающий всех(и удерживающий от fork-ания ветки).

> Конфиг, в первую очередь, должен быть для людей. Развели мышевозил гуёвых...

+1 умиляют порой такие персонажи, которые в синаптике наворочают вообще не осознавая что происходит и удивляются - какого ж хера у них ничего не работает

Даеш реестр в линуксе!

>Так вот, п1: сейчас есть то же самое дерево с данными, его корень - в /etc, там можно задавать кучу разных прав всем узлам.

что курил?

>Там слишком много фич, которые не нужны для конфигов.

перечисли

>Вы говорите про обработку ошибок и схемы? Да их же заипёшься писать!

а их не надо писать. Они уже написаны

>Тем более, что обработка ошибок на ура делается в приложении, которое и использует конфиг

каждому приложению по валидатору! каждой программе по скрипту, вытягивающего данные из ldap и генерирующего конфиг!

Хм... Мне так нравятся пингвиноиды! Несколько лет они через жопу с костылями решают тривиальные задачи. В это же время под оффтопик существует прекрасное решение проблемы. Наконец, зоипавшись в доску, отчаянный пингвопрогер решается применить ненавистное решение мелкомягких - вуаля! Всё прекрасно работает. НО(!) при этом решение называется велосипедом. ПОЧЕМУ?! Велосипед-то он ТОЛЬКО ПОД ВИНДОВЗ, а раз у Линукса не было решения, значит извините - это "свежее решение"!

Вообще, не торопитесь выражать своё убогое мнение, не посмотрев досконально картину. Люди не любят писать велосипеды и если они уж пишут, то значит существующие решения их не удовлетворяют! Или могли БЫ удовлетворить, если бы автор программы хоть раз бы сел и написал НОРМАЛЬНУЮ ДОКУМЕНТАЦИЮ, объясняющую все аспекты достижения нирваны.
А раз нет ОЧЕВИДНЫХ путей удовлетворить юзера - он пишет велосипед. Хороший сигнал остальным посмотреть на свои убожества и подумать - почему люди продолжают делать клоны.

>Тем, что там много лишних слов писать надо.

продемонстрируй "лишность". Угодай как-то слил

666!!! вы все сгорите в аду!!!

>В это же время под оффтопик существует прекрасное решение проблемы.

какое, если не секрет?

А почему бы не объединить решения XML + Windows Registry? В обычном режиме работает системный API для доступа к иерархической системе конфигов. А в админском можно залезть в этот самый реестр (XML-ный) и руками подправить сбойные ветки.

Центральный реестр нужен однозначно, потому что помойка из трёх букв ETC - это архаичное решение 70-ых, под которое затачиваются остальные программы (вплоть до привязки к именам файлов!). Накой это нужно? В BSD - одно, в Линуксе - другое, в соплярисе - третье... Потому и всякие autoconf существуют, что нет единого метода указать конфигурацию - сплошные хаки и suggestions.

Короче, пингвинукс ещё пилить и пилить.

>А почему бы не объединить решения XML + Windows Registry?

XML неудобно в ldap хранить

тада уж embedded parser SQL-а прямо в FS, A-la ReiserFSv4, в которые - пихаем "/etc-помойку". уж по удобству и перформансу - оно будет иметь ввиду и зюмль и расширения plaintext - вместе взятые.

p.s. назовем это, для простоты - Ext5

2matumba

Чувак - закрой америку - да? Тут тебе уже 500 раз про эту штуку рассказали. Ей десяток лет пользуются уже. Иди погуляй - да?

"помойка из трех букв" - чинится "руками" помойка "реестр", даже с применением очень sophisticated софта для работы его ODS-контейнером(в случае повреждения, либо чего похуже с самой ОС).

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

>Надо ли понимать этот вопрос как утверждение о том, что некоторые люди ни чем уже не брызгают ?

Так и запишем, все сторонники зюмеля уже полностью потеряли свою мужскую силу.

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

у "внешней" схемы, отделённой от приложения есть преимущество, когда нужно конвертировать один формат в другой. Если есть схема, достаточно для конвертации из N форматов входных в M выходных написать N+M конверторов ( из своего в универсальный, и наоборот), а если схемы нет и валидация лежит на приложении-конверторе, то придётся писать N*M форматов.

Другой вопрос, а зачем конвертировать конфиг одной программы в конфиг другой, если можно её просто попросить саму прочитать/записать конфиг в нужном формате.

Например, как в МакОСи, там есть стандартный формат для персистентных объектов -- plist, который обычно отображается на XML. Персистентные объекты можно собрать и сериализовать/десериализовать сторонней утилитой, "заморозив"/"разморозив" состояние программы в любой момент времени (интроспекцией). Поэтому то, что у каждой программы может быть свой проприетарный формат конфигов или данных, не мешает написать тот же поиск Spotlight по данным или разбор конфигов прозрачно для других программ системы. То есть, просим программу прочитать свой конфиг, делаем снимок plist, делаем изменение, делаем ещё один снимок plist, просим программу сохранить конфиг, тупо сравниваем снэпшоты plist между собой. Всё, мы научились сохранять данные в формате конфигов этой программы.

и для КОГО - в этом преимущество ? а для кого - МИНУС ?

ведь спор о том и идет - простота для девелоперов и безпроблемность для сисадминов - НЕ ДРУЖАТ. первым нужно "трэшэ-круто-монструозно-гибко-хитрое" нечто, чтобы вынеси максимум логичи, ЗА ПРЕДЕЛЫ того, за что они отвечают(рублем, а порой и - ГОЛОВОЙ). вторым - чтобы этого всего - НИКОГДА не было в ИХ сети.

> Центральный реестр нужен однозначно, потому что помойка из трёх букв ETC - это архаичное решение 70-ых, под которое затачиваются остальные программы (вплоть до привязки к именам файлов!). Накой это нужно?

это ортогонально. Если накроется общий реестр, больно будет всей системе. А если только конфиг одной программы в /etc/ - то 1) восстанавливаем /etc/config из git 2) удаляем или копируем из примера в пакете программы, и запускаем прогу с дефолтным конфигом.

>В BSD - одно, в Линуксе - другое, в соплярисе - третье...

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

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

То есть, реестр вообще не занимается хранением конфигов (или просто имеет кеш, который можно воссоздать). Реестр это просто view, унифицированный интерфейс доступа к произвольным настройкам. А сами настройки хранит та конкретная программа в том конкретном формате, который именно ей нужен.

пример "вторичного" реестра - NIS, LDAP :)

anonymous побрызгал на argin.

>Если накроется общий реестр, больно будет всей системе.

примеры в студию. Какие ошибки реестра приведут к "накрыванию"

хранение конфигов /boot/grub *только* в реестре :))

>хранение конфигов /boot/grub *только* в реестре :))

хранение конфигов бутлодера даже в венде не практикуется.

> прямо в FS, A-la ReiserFSv4, в которые - пихаем "/etc-помойку"

>>Так вот, п1: сейчас есть то же самое дерево с данными, его корень - в /etc, там можно задавать кучу разных прав всем узлам. Интерпретация данных так же зависит от приложения(!)

то, что в трех соснах xorg-server/evdev/hald и двух велосипедах драйверов присутствуют свои NIH-велосипеды, навевает мысль о необходимости общеситемного механизма вроде реестра по смыслу, семантически, только проще и прозрачнее в реализации

вот Plan9/inferno умеет union bind'ы по-разному для разных пользователей, но прозрачно для системы в целом, и прозрачно отображает некий абстрактный /prog/#pid/window в единственный с точки зрения этого конкретного приложения /dev/window.

Так почему бы не придумать 0) транслятор велосипедного /etc/prog/config в "унифицированный" /prog/#pid/config или /dev/config (с "внутренней" точки зрения программы #pid) 1)"репликатор реестра" из такого /dev/config в NIS,LDAP 2) универсальный интерфейс этого /dev/config (типа key=value, plist, произвольный API, описанный далее в самом /dev/config) 3) программный интерфейс какого-то libdevconfig (c деревьями, тегами, и т.п.) 4) "конвертор" разных libXXXconfig в универсальный libdevconfig. "Интерпретация конфигов зависит от приложения", так выделить её явно в библиотеку libXXXconfig и конвертировать по смыслу в некий универсальный вид libdevconfig.

то есть, "виртуальный псевдореестр" -- это в первом приближении расстановка системных тегов на конфиги "/etc-помойки" и доступ по этим универсальным тегам к унифицированным конфигам (другого приложения) в /dev/config. Например, xorg-server имеет отдельный conf для настроек сервера, и отдельный для настроек, общих с драйвером. А драйвер потом читает по нужному тегу только его подветку настроек.

0) Некий демон связан с пакетным менеджером, и отображает /etc/progname/config на /dev/config/dir1/conf1. 2)Прога может по старому работать с уникальным велосипедом в /etc или пользоваться унифицированным метро-интерейсом вроде /dev/config. 3)При этом она может писать конфиги в /dev/config по тегам (стандартным, унифицированным, но расширяемым пользовательскими), а другая программа -- по этим тегам обратиться (в идеале, нужно что-то подобное и с интерфейсами для libXXXconfig. Чтобы одна прога могла попросить другую что-то там изменить в конфиге). 4) /dev/config может отображаться на "нативный" /etc/prog/config конверторами вроде libXXXconfig. то есть, интерфейс работы с конфигом libXXXconfig должен сам передаваться через /dev/config конкретного приложения ХХХ.

в вянде зато практикуется назначение букв дисков разным разделам (частично хранится в реестре, частично на лету) и загрузка дров с непонятно как назначенной буквы раздела, а не с GUID/volname метки.

Типа как почему винда не грузится если не выставить generic ide контроллер и поменять материнку. Не запускается дрова контроллера, съезжает назначение буков, и не находится /boot раздел с остальными дровами. Можно починить, если руками залезть в реестр и поправить буквы на нужные, и подставить generic ide в реестре руками.

>в вянде зато практикуется назначение букв дисков разным разделам

это уже проблемы венды

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

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

это ты проблемы реализации описываешь, а не проблемы реестра

>>Ерунды там в конфиге многовато, например моделайны эти дурацкие

>У меня ноут с разрешением 1024х600, так что без Modeline тоскливо.

>По теме: xorg много памяти жрет. Конфиг же его вполне удобен и легко читаем, что большой плюс - при возникновении каких-либо проблем с графикой можно оперативно их решить, а редактировать графические настройки только в графическом режиме - это чистый windows-way: не запускаются, к примеру иксы - придется систему всю переустанавливать???

Хм, а nautilus, gnome-panel не много жрут? или gnome-keyboard-applet который жрет памяти как треть иксов? Просто тупо апплет показывающий какая у тебя сейчас раскладка.

в этом и прикол Two-Way SQL<-->FS. везде однозначное соответствие. дрова видео, /etc-у на СКЛ-е: "какие у нас там моделине ?" FS-дрова(или даже скллайт, пока писать FS будут), видеодровам: "ну это, как-бы, вот и вот(2d-array в ответ и BLOB-ов, "скока надо", до кучи")" пользвователь: "акуеть !!! дайте две !!!!" программист: "все ! идем пить пиво !!"

пис-пис, гармония(после пива и окончания работы - соотв).

p.s. никто не спорит, что СКЛ - круче зюмля ? :) и как интерфакес и как лэнгвич для оного.

угу, а Виндовз - как частный случай ужасной реализации, "прекрасно-волшебной", потенциально, ОС ? в таком случае - разницы принципиальной, End-User-у(будь то домохозяйка, сисамдмин, или финансовый директор) - разницы нет - В ЧЕМ ИМЕННО, причина.

>p.s. никто не спорит, что СКЛ - круче зюмля ? :)

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

очень содержательное критическое замечание. я юзать виндоз(или xml применительно к задачам уровня хранения(темп)конфигов одной из подсистем ОС) - может только Кретин. особенно - на сервере. это уже "мастурбирующе-мартшечный кретин" (c) Линус

p.s. вам-же ничто не помешало зачем-то(ЗАЧЕМ ? :) сравнивать хмлы с текстом ? :)

>очень содержательное критическое замечание

что не нравится? Не знаешь, в чем разница между xml и sql? Так учи матчасть и не позорься

1. никто не сравнивал xml и SQL. f2f-mode 2. сравнивалcя интерфейс доступа к данным, конфига, stored in 2way FS<->SQL-базе 3. матчасть знаю. де-факто(работодатель не в претензии). 4. речь шла о том, что коли уж пошли "техничность" наращивать решения, надуманной(IMHO), проблемы, почему не СКЛ ? всяко структурированнее и техничнее буит -) всяких к-но-зюмлей :-) зюмль - это когда надо инфо "с ноготок" хранить, мало-мальский "по людски", а программисту - ВСЕРЬЕЗ, "ну очень не хочется" писать.

и таки-опять малосодержательная "реплика с места" да еще с переходом на личности ? аргументы исчерпаны ? :) слили ? :)

>Порадовало с www.reactos.ru: "Многие последователи UNIX используют для вывода графики ставшвую стандартом де-факто стандартом систему X-Window, которая также обладает, возможно, одной из худших архитектур в истории развития программного обеспечения." Полностью поддерживаю. chislennye_metody (*) (19.07.2008 16:06:27)

По сцылке лень ходить, не тру это. Но, надеюсь, дальше по тексту идет АРГУМЕНТИРОВАННОЕ обоснование их позиции или, как сейчас принято в среде "революционеров", одни голые слова и громкий пер..., гм! ...ар.

>почему не СКЛ ? всяко структурированнее и техничнее буит -) всяких к-но-зюмлей :-)

противоречит

>1. никто не сравнивал xml и SQL.

определись уж

запросы структурированные(СКЛ) vs структурированные таблицы(зюмль) - всяко разное. но и по оверхэду "в деле" и по издержкам "на .."- зюмлб соседЪ.

p.s. по той-же причине - все и ушли, в свое время - с ФС БД на СКЛ и (затем)на Гибридные(СКЛ-обьектные)и обьектные БД.

он стабилизирован/стандартизован ? да и сторонней проге зависеть от куска стороннего проекта это не кул

Он входит в стандартную поставку xorg. как ещё нужно его стандартизировать?

>Опять же оверхед на обучение им пользоваться итд. итп.

А каким парсером не надо учиться пользоваться?

>А каким парсером не надо учиться пользоваться?

libastral

парсер "plaintext", ставится и тюнится во время получения первичного образования в школе. в моск. всем будующим IT-шникам и прочим "домохозяйкам" когда туда прийдут(широко распахнув двери)XML и (возможно) ООП - я буду только рад !

p.s. может лучше о пиве и ценах на колбасу ? :-?

>парсер "plaintext", ставится и тюнится во время получения первичного образования в школе.

в какую школу надо отправить гуевую конфигурялку, чтобы в ней можно было настроить sendmail?

ГУЕ-вую ? наверное только в Ивано-Франковскую, "для особо одаренных" все навреное, помнят, КАК СИЛЬНО теряли в красочности - учебники после 1-го или 2-го класса(смотря в какую ЭРУ - Вам довелось учиться(в школе)) ?

так и тут - отойдя в сторонку от парсеров, "волей-неволей", наличествующих у всех(обсуждать многовековые организации, чья деятельность, сделала, это - обыденным явлением - пока не стоит :), мы уперлись рогом в очередную попытку "революционизировать на ровном месте", часть ОС, cовершенно, того не заслуживающую :) и прекрасно работающую(вопреки критике(содержательно и не особо))

p.s.

"работает ? НЕ ТРОГАЙ !!!" (c) (r)

>ГУЕ-вую ?

телепатическую. Автоматическую. Кластерную. Какую угодно.

[дальнейший поток несвязных подделок под мысли ниасилен, звиняйте]

"Поплывёт" структура дерева. Например, какая-то прога переименует одну из ветвей около корня. Чтобы этого не было - нужны права. Права, как и структура дерева есть в ФС.

Ещё раз, насчёт "уже написанных схем для валидации хмл". Итак, у меня есть программа, ей нужны пять чиселок, чиселки зависят друг от друга. Мне не вкатывает описывать эту зависимость в схеме, ибо, тогда у меня будет разделены две сущности. И вообще, проще делать проверки прямо в коде, чтобы ничего не падало.

Да, кстати, в случае текстовых конфигов в /etc я могу их очень просто забекапить, выполнив "интуитивную" операцию копирования. Могу их сравнить с копией с помощью какой-нить мерджилки/диффалки. А что мне делать, если будет gconf?

>"Поплывёт" структура дерева. Например, какая-то прога переименует одну из ветвей около корня.

а кто ей даст?

>И вообще, проще делать проверки прямо в коде, чтобы ничего не падало.

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