LINUX.ORG.RU

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

 , ,


0

0

Уже давно очевидно, что хранение настроек иксов в xorg.conf устарело и не справляется с возложенными на него задачами, в связи с чем, например, писатели проприетарных драйверов от AMD/ATI и NVIDIA изобрели собственные реестроподобные велосипеды.

Недавно по этому поводу разгорелась дискуссия среди разработчиков иксов, в ходе которой было выдвинуто несколько смелых идей — в их числе, например, хранение настроек в GConf. Мэтью Типпет из AMD рекомендовал использовать иерархаичную конфигурацию, сходную с решением в проприетарных драйверах ATI. «NIH syndrome always rules...» — отметил он.

>>> Подробности в репортаже Phoronix

★★★★

Проверено: JB ()
Ответ на: комментарий от geek

> а почему не plain text?

Что-то не сооброжу. Был xorg.conf в plain text. Станет xorg.conf в реестре в plain text? Что было, то и осталось. Чего ради затевать изменения?

> Боженька запретил?

Ну, тут много плакались о тяжёлой судьбе писателей парсеров для plain text. Неужто врали?

ugoday ★★★★★
()
Ответ на: комментарий от Absurd

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

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

>Ну это как "повторное использование кода" vs "отсутствие явно лишних зависимостей". Серебрянной пули тут нет и обдумывать проектные решения надо хорошо.

о чём и речь. Профит при грамотной реализации обещает быть большим. А если сделать "как в венде" - то да, лучше не делать вообще

geek ★★★
()
Ответ на: комментарий от LamerOk

> Покажи мне связь DBUS с bind, httpd.conf, alsa.conf и xorg.conf )))

Когда все эти конфиги положат в реестр, будешь за ними ходить через DBUS.

Aceler ★★★★★
()
Ответ на: комментарий от sin_a

>По моему это как раз пример идеальной стыковки.

Не сказал бы... вот пример сузя. Там есть sysconf. Дык вот, ежели есть то, о чем не знает yast, то путь только один - полностью брать управление конфигами на себя.

В случае со стандартизированным etc (пусть это даже будут файлики вида apache.conf и каталогов apache.conf.d), это уже не требуется, т.к. первыичны файлы в /etc, а не как сейчас часто где-то еще, а уже сами конфиги со страшными надписями "DON'T EDIT".

anonymous
()
Ответ на: комментарий от LamerOk

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

Это, наверное, так. Но общая стоимость зависит и от эффективности инструмента. Если Вы учёный, то однозначно научный калькулятор будет для Вас гораздо дешевле(читай эффективней) чем обычный, несмотря на обучение и стоимость самого калькулятора. А если продавец, то безусловно научный калькулятор для Вас - лишь затраты по сравнению с обычным. Хотя по сравнению со счётами - всё равно выходит что научный калькулятор гораздо дешевле счёт.

AndreyKl ★★★★★
()
Ответ на: комментарий от geek

> а ока - это аргумент в споре "автомобили говно"

Если бы Ока была единственным в мире автомобилем, то таки да, автомобили были бы говном.

tailgunner ★★★★★
()
Ответ на: комментарий от geek

> венда реестр не кеширует.

Бгг. Она его очень даже кэширует, в реестре есть даже настройка размера кэша.

> понятия "приложение - владелец ключа" там нету.

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

tailgunner ★★★★★
()
Ответ на: комментарий от ugoday

>Что-то не сооброжу. Был xorg.conf в plain text. Станет xorg.conf в реестре в plain text? Что было, то и осталось. Чего ради затевать изменения?

ну, может для того, чтобы читать и писать конфиг xorg.conf без проблем могли другие приложения?

>Ну, тут много плакались о тяжёлой судьбе писателей парсеров для plain text. Неужто врали?

plain text - это миф. Его не существует. =)

geek ★★★
()
Ответ на: комментарий от geek

> концепция не может быть плоха реализацией =)

Концепция, которую никто никто не реализует из-за сложности/невозможности реализации, плоха. Нет?

anonymous
()
Ответ на: комментарий от LamerOk

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

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

AndreyKl ★★★★★
()
Ответ на: комментарий от geek

> читать и писать конфиг xorg.conf без проблем могли другие приложения?

пусть проблемы с чтением/записью будут у приложений, чем у меня.

> plain text - это миф. Его не существует

Нео? Поведай, о Избранный, и в каком же ныне формате пребывает нечестивый xorg.conf?

ugoday ★★★★★
()
Ответ на: комментарий от tailgunner

>Бгг. Она его очень даже кэширует

в памяти?

>Никто не мешает приложению создать свою ветку.

не тупи, а?

geek ★★★
()
Ответ на: комментарий от Aceler

> Ну нет у неё пока нормальных реализаций, за исключением, пожалуй, LDAP.

У LDAP покамест есть большущая проблемка - отсутствие стандарта (да и реализаций) на транзакции. Что сильно сужает его возможности.

Хотя реально достаточно толковая вещь, использую у себя. Инструментов только толоковых маловато.

anonymous
()
Ответ на: комментарий от geek

> синтаксис. у реестра. Ты что куришь?

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

> Так что давай без высосаных из пальца аргументов

Так их нет. Если ты хочешь на своей мабиле демон реестра - это твои трудности. Никто из разработчиков такой фигней страдать не хочет.

> Какой язык используется в /etc/logrotate.conf ? А в /etc/X11/xorg.conf?

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

> Я бы столько веществ физически не выдержал бы

Молод ищщо. Умишком слаб. Покурии для разнообразия хотя бы пролог. Это всем студентам на специальностях "программирование" положено по курсу.

LamerOk ★★★★★
()
Ответ на: комментарий от geek

>> Бгг. Она его очень даже кэширует

> в памяти?

Да.

>> Никто не мешает приложению создать свою ветку.

> не тупи, а?

Только после Вас :)

tailgunner ★★★★★
()
Ответ на: комментарий от ugoday

>пусть проблемы с чтением/записью будут у приложений, чем у меня.

а у тебя проблемы с чтением и записью? Сочуйствую

>Нео? Поведай, о Избранный, и в каком же ныне формате пребывает нечестивый xorg.conf?

размеченные структуры с парами ключ/значение

geek ★★★
()
Ответ на: комментарий от Aceler

> Когда все эти конфиги положат в реестр ...

Интуиция мне подсказывает, что идея geek'а не найдет поддержки у широкой общественности. )))

LamerOk ★★★★★
()
Ответ на: комментарий от ChALkeR

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

Неужели так сложно забахать по конфигу каждому? Али места не хватит на нынешних многогиговых винтах?

anonymous
()
Ответ на: комментарий от geek

> а у тебя проблемы с чтением и записью?

Это зумля-то? Ага. Есть проблемы. Все глаза изломаешь, пока сквозь буреломы тэгов проберёшься. А глазки не казёные.

> размеченные структуры с парами ключ/значение

это и есть plain text.

ugoday ★★★★★
()
Ответ на: комментарий от AndreyKl

> Но общая стоимость зависит и от эффективности инструмента.

Это входит в оценку геммороя. Учитывается (объем работы || время работы)*эффективность инструмента.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

>конвертировал его обратно во внутреннее представление - маразм в последней стадии.

сам ты маразматик. Писать парсер для каждого такого предствления в текстовом виде - дебилизм. Заставлять сторонний софт переписывать этот парсер, если ему нужно посмотреть в этот конфиг - двойной дебилизм.

anonymous
()
Ответ на: комментарий от AndreyKl

> Задачи разные - значит нужны разные инструменты (возможности) - значит больше возможностей

И появляется задача по выбору инструмента, которая добавляет к этим возможностям еще геморроя. ))

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> Это входит в оценку геммороя. Учитывается (объем работы || время работы)*эффективность инструмента.

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

AndreyKl ★★★★★
()
Ответ на: комментарий от geek

> речь шла о чтении из xml-файла

Ой, правда? 8)

>>>> венда реестр не кеширует.

>>> Бгг. Она его очень даже кэширует, в реестре есть даже настройка размера кэша.

>>В памяти?

>Да

Ну а про XML вё уже сказано - народ не хочет зюмеля. В роли обертки для пар ключ-значение что угодно лучше, чем XML - хоть ini, хоть JSON, хоть shell vars. Это не говоря о том, что отнюдь не любой конфиг является набором ключей.

tailgunner ★★★★★
()
Ответ на: комментарий от ugoday

>Все глаза изломаешь, пока сквозь буреломы тэгов проберёшься. А глазки не казёные.

Это хорошо, если конфиг знакомый... а если нет?

В xml хотяб подкрашивается стандартно. Тем же vim-ом http://www.pinkjuice.com/howto/vimxml/intro.xml

ЗЫ: хотя возможен вариант, что это какой-то bw моник... но тогда сочуйствую и рекомендую сменить работу :)

anonymous
()
Ответ на: комментарий от anonymous

>нынешних многогиговых винтах?

на нынешних винтах хватит и на "по файлу на опцию, и каталоги для иерархии" - по моему это должно юниксвей-дебилом больше всего нравится, "ведь файлы!!!"

anonymous
()
Ответ на: комментарий от LamerOk

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

слушай, а давай я тебя геем буду называть просто на том основании, что _я так понимаю_ будто гей - это тот, кто против реестра? =)

>Так их нет. Если ты хочешь на своей мабиле демон реестра - это твои трудности. Никто из разработчиков такой фигней страдать не хочет.

>Декларативные в обеих случаях.

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

>Молод ищщо.

бугого

>Покурии для разнообразия хотя бы пролог.

дважды бугого

geek ★★★
()
Ответ на: комментарий от tailgunner

>В роли обертки для пар ключ-значение

кто тебе сказал что потребности конфигов на этом заканчиваются ?

anonymous
()

Извините, всё тему не читал. Один вопрос: это правда что конифиг sendmail перепишут на XML?

anonymous
()
Ответ на: комментарий от anonymous

> Писать парсер для каждого такого предствления в текстовом виде - дебилизм.

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

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

Разумеется. man opensource, Luke.

LamerOk ★★★★★
()
Ответ на: комментарий от tailgunner

> Это не говоря о том, что отнюдь не любой конфиг является набором ключей

Не могу придумать соответствующий пример, особенно в контексте топика.

Sphinx ★★☆☆
()
Ответ на: комментарий от tailgunner

>Ну а про XML вё уже сказано - народ не хочет зюмеля.

народ так и ниасилил объяснить - почему

>В роли обертки для пар ключ-значение что угодно лучше, чем XML - хоть ini

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

>хоть JSON

жжошь, воистину

>хоть shell vars

тоже жду примерчик

>Это не говоря о том, что отнюдь не любой конфиг является набором ключей.

если конфиг является _скриптом_ - это совсем другой вопрос. Хотя бы потому что это уже _не_ конфигурационный файл, а скрипт инициализации

geek ★★★
()
Ответ на: комментарий от anonymous

> В xml хотяб подкрашивается стандартно.

разукрашеный зумль всё равно менее удобен, чем набор пар ключ-значение

ugoday ★★★★★
()

А нельзя абстрагировать уровень доступа к настройкам? Чтобы утилиты имели бы прозрачный доступ к настройкам через эту абстракцию. Соответственно, в зависимости от типов конфигов, она (абстракция) могла бы генерить/читать xml/text/lightsql etc?

anonymous
()
Ответ на: комментарий от anonymous

>> В роли обертки для пар ключ-значение

> кто тебе сказал что потребности конфигов на этом заканчиваются ?

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

tailgunner ★★★★★
()
Ответ на: комментарий от LamerOk

>кривом и никак не подходящем для нее языке - не дебилизм?

профессора СS которые борд мемберы w3c, и другие высококвалифицированные специалисты смеялись над тобой. Да кто ты такой чтобы вякать про субъективные критерии? Пипиську то втяни обратно.

anonymous
()
Ответ на: комментарий от geek

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

А давай ты сначала объяснишь, почему задачи вдруг неожиданно оказалисть "одними и теми же"? ))

> дважды бугого

Так вот от кого шмалью пахнет...

LamerOk ★★★★★
()
Ответ на: комментарий от tailgunner

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

anonymous
()
Ответ на: комментарий от AndreyKl

> Но в любом случае вся наша цивилизация с этой точки зрения - постоянное добавление возможностей

Увы. Не добавление, а замена. Менее эффективных на более эффективные путем естественного отобора. Количество осваиваемых возможностей все равно ограничено человеческими способностями.

LamerOk ★★★★★
()
Ответ на: комментарий от ugoday

>Это зумля-то? Ага. Есть проблемы. Все глаза изломаешь, пока сквозь буреломы тэгов проберёшься. А глазки не казёные.

use-case в студию, когда тебе приходится "глаза изламывать"

>это и есть plain text.

неа. у xorg.conf - простейший markup text. А по твоей логике и xml - plain text =) И конфиг сендмыла - plaintext. Ага?

geek ★★★
()
Ответ на: комментарий от ugoday

>Конкретно для xorg.conf этого вполне достаточно.

нифига не достаточно. Там дерево.

а обеспечивать иерархию через NodeA.NodeB=value; не один инженер себе не позволит.

anonymous
()
Ответ на: комментарий от Sphinx

> Не могу придумать соответствующий пример, особенно в контексте топика.

давай, покажи мне как будет выглядеть ~/.stumpwmrc в xml-варианте, а я посмеюсь.

anonymous
()
Ответ на: комментарий от Sphinx

> Поздравляю, ты описал GConf :-)

GConf особо не знаю, а разве через него можно использовать в качестве конфигов тот же plain text?

anonymous
()
Ответ на: комментарий от anonymous

>а почему права доступа не может контроллировать файловая система с ACL? Опять этот NIH-синдром

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

geek ★★★
()
Ответ на: комментарий от anonymous

> все незадроты хотят стандарта.

Скажи, а уже все незадроты сошлись во мнении, каким именно будет стандарт? Или только профессора CS из w3c?

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

> давай, покажи мне как будет выглядеть ~/.stumpwmrc в xml-варианте, а я посмеюсь.

конфиг mldonkey то же фиг засунешь в хмель.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.