LINUX.ORG.RU

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

 , ,


0

0

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

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

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

★★★★

Проверено: JB ()

Ответ на: комментарий от Zubok

> GConf тут понятно, откуда появился. Речь там зашла о том, чтобы хранить настройки не только в /etc/xorg.conf, но и у юзера, так как у разных пользователей на машине могут быть разные предпочтения по железу (например, своя клава, свои настройки параметров пада или вакома какого-нибудь и т. д.). GConf позволяет не только хранить параметры заданным образом, но и предоставляет кое-какой дополнительный сервис (например, сообщение об изменении параметра заинтересованным приложениям)

Я по этому поводу уже выше ответил.

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

Угу, а править это без спецтулз не потеря времени ? Ну ненужен в линуксе реестр - первый шаг к окончательному положению на KISS.

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

>Угу, а править это без спецтулз не потеря времени ? Ну ненужен в линуксе реестр - первый шаг к окончательному положению на KISS.

XML != реестр.

реестр != GConf. (освещение этого вопроса производится geek и svu)

я про XML говорил, но не про реестр.

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

> XML != реестр.

XML == много времени на ручную правку конфигов.

А давайте вообще все настройки хсервера в базе данных хранить ? И в ядро это все интегрируем.

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

>>(проприетарные дрова >>идут нафиг или переписываются), потом делают всё остальное.

И то верно. Перестаньте выпускать уже все эти проприетарные драйвера, пусть линукс сдохнет через пару лет(кому он нахер нужен без современного видео-то?).

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

да причём там реестры! просто аналоговый монитор под иксами настроить правильно - это же с бубном прыгать надо! вот проблема то где!

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

>Gconf рулит, особенно в свете отрывания его от гнома и от гтк.

Линаксокапец?

>омфг, а что сказал Патрик по этому поводу?

Слег наверно

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

>А давайте вообще все настройки хсервера в базе данных хранить ? И в ядро это все интегрируем.

+много. Лучше всего подойдет Оракл.

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

>А давайте вообще все настройки хсервера в базе данных хранить ? И в ядро это все интегрируем.

Это не ко мне. :)

>XML == много времени на ручную правку конфигов.

Это ко мне. Сколько времени мы тратим на редактирование конфига иксов? У некоторых -- это раз в жизнь происходит. Я, так как начал сопровождать драйвер для Xorg, это делаю очень часто, а до этого спокойствие было очень долгим. Так что это событие для человека умеющего править конфиги, очень редкое. Да и XML не настолько сложен в редактировании, на самом деле (хотя лучше бы это были s-expressions :), и для построения программ для конфигурации предоставляет куда больше удобства. И не для пользователей (им все-равно, как программа ходит и где что переписывает), а именно для программистов.

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

Section "answer"
Driver "human"
Identifier "XML"
Option "fail"
Option "unreadable"
InputDevice "Generic Keyboard"
EndSection

Ну, кстати, конфиг иксов и без того древовидный, разницы с XML и не будет.

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

>да причём там реестры! просто аналоговый монитор под иксами настроить правильно - это же с бубном прыгать надо! вот проблема то где!

Действительно, причем реестры? Где про них речь у меня? Что цитируем-то? :)

Проблема настройки монироров ортогональна проблеме, о которой спорят в этом топике.

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

Не в том дело, подобное в хорге станет прецедентом. Потом (вспоминая неадекватное поведение Линуса в последнее время) конфиг ядра в xml будет.

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

Плюс один к s-выражениям. Львиная доля противности XML в том, что угловые скобки смотрятся агрессивно. В то же время, круглые скобки милы и няшны.

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

>да причём там реестры! просто аналоговый монитор под иксами настроить правильно - это же с бубном прыгать надо! вот проблема то где!

Может пора потихоньку аналоговые мониторы на помойку выносить, а не форматы конфигов под них подстраивать?

P.S. Кстати, не припомню ни одного случая лет... эдак за десять, чтобы были какие-то проблемы с настройкой аналоговых мониторов, или чтобы меня чем-то не устраивал формат файла xorg.conf.

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

>Да там в любой раздел GConf зайдешь и ужасаешься. XML не для конфигов. >Не надо стрелять из пушки по воробьям. XML - для хранения больших >объемов структурированных данных.

может для БОЛЬШИХ объемов SQL?

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

Бесполезные и глупые сообщения пишешь ты, дискриминируя пользователей и разработчиков KDE.

GFORGX ★★★
()

А, давайте... а давайте - всё унифицируем! Давайте повыкидываем нафик все эти текстовы конфиги, скрипты, make, shell, rc, файловую систему, базы данных - ну, одним словом абсолютно всё! А вместо этого всего - разметим винчестрер, под один большой-пребольшой XML файл! - Вот, где красота! Тут тебе и биос, там тебе и ядро, и конфиги к нему, и скрипты загрузочные, и файлы устройств, и обычные файлы, и специальные, и каталоги, и симлинки, и процессы, и каналы, и редакторы всякие, программы нужные (MSO например), и игры разные интеллектуальные (Diablo), и всё-всё есть - аж глаза разбегаются от такого изобилия, и всё это великолепие - в одном XML файле! Только ты, и XML парсер (также встроенный в этот XML файл) - чистое творчество!

anonymous
()

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

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

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

>http://lists.freedesktop.org/archives/xorg/2008-July/037222.html

Хотя вот в этом сообщении автор ткнул в deviceControl(). Действительно, такая штука есть, но она, похоже, только для устройств ввода, но для видеодрайверов отсутсвует. Новая система, наверное, будет для всего. Надо уточнять. Вот цитата из http://www.x.org/wiki/XOrgInputDriverSpec :

>Another feature that has been neglected is the use of the deviceControl() functions intended to be the primary control point for XInput drivers, as documented in the Xi docs and implemented in DIX. It is a well defined, clean design, and should be used. In fact, the same design could be ported to the video drivers as well, to provide a uniform driver design that is (arguably) better than the current design.

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

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

Пусть эти создатели недовиндовс засунут своё мнение, в задницу своим мамам.

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

1. Язык, на котором написан xorg - C - считаю устаревшим. 2. Зачем надо дублировать функциональность: xorg, fbdev? 3. Архитектура xorg кажется слишком раздутой, немногие используют клиет и сервер x11 на разных компьютерах. Вот еще по поводу протокола x11: "Недавняя статья в Линукс журнале [Linux Journal] о NoMachine и NX протоколе показывает, что протокол X может быть ужат в соотношении 200:1 и больше." (http://www.opennet.ru/docs/RUS/linux_graphics/).

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

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

XML как раз на лету не изменяется. Чтобы что-то изменить, надо его сначала распарсить в дерево, потом изменить, а потом записать обратно. UNIX-way и текстовые потоки идут лесом и нужно писать новые утилиты для работы с XML (которые для изменения 10 параметров будут 10 раз парсить конфиг).

>The most serious problem with XML is that it doesn't play well with traditional Unix tools. Software that wants to read an XML format needs an XML parser; this means bulky, complicated programs. Also, XML is itself rather bulky; it can be difficult to see the data amidst all the markup.

>…

>XML can be a simplifying choice or a complicating one. There is a lot of hype surrounding it, but don't become a fashion victim by either adopting or rejecting it uncritically. Choose carefully and bear the KISS principle in mind.

(The Art Of Unix Programming)

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

Так потому и

> вроде бы новая система уже есть.

что shm для этого очевидно NOOOOOOO!

Точнее, её вырабатывают. Как я понял АТИшники (или это xf86-video-ati?) своих костылей уже наворотили. Кстати, не знал про dconf. Напрашивается топик «Что придёт на смену GConf?», лол.

А какой ты драйвер курируешь?

Sphinx ★★☆☆
()

и все совсем не таг:
иксы должны работать искаропки, а их конфиг
1) lsattr +i
2) бинарный, шифрованный неизвестным ключем.


За компутером работать нужно, а не иксы настраивать :-)

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

> Архитектура xorg кажется слишком раздутой, немногие используют клиет и сервер x11 на разных компьютерах.

NONSENSE, только благодаря этой архитектуре протокол не меняется 11 лет, ящитаю.

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

>Вот еще по поводу протокола x11: "Недавняя статья в Линукс журнале [Linux Journal] о NoMachine и NX протоколе показывает, что протокол X может быть ужат в соотношении 200:1 и больше."

Проблемы X протокола ортогональны NX. Высказываю свою точку зрения. X-протокол это чистая реализация обмена без всяких эвристик и кеширований, и сжатий, которые и не должны присуствовать в этой спецификации. Эти алгоритмны могут от случая к случаю, от реализации к реализации меняться -- уже были всякие варианты LBX Кейта Паккарда, и тот же NX, и еще другие будут. Так что всякие дополнительные ужимания -- это дело прокси-уровня. Прокси-уровень может быть частью реализации X-сервера (как модуль, например), но в протокол лезть не надо.

Первые два аргумента комментирвоать не буду.

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

> XML как раз на лету не изменяется. Чтобы что-то изменить, надо его сначала распарсить в дерево,

Да XML это всего лишь одно из представлений. Сам характер используемых данных предполагает зависимость от контекста (то есть, нужные структуры данных находятся в древовидно иерархии), поэтому Unix tools в любом случае идут лесом. inb4 9P.

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

>Чтобы что-то изменить, надо его сначала распарсить в дерево, потом изменить, а потом записать обратно. UNIX-way и текстовые потоки идут лесом и нужно писать новые утилиты для работы с XML (которые для изменения 10 параметров будут 10 раз парсить конфиг).

Есть такая вещь как SAX.

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

>3. Архитектура xorg кажется слишком раздутой, немногие используют клиет и сервер x11 на разных компьютерах.

Э, так вот ты и получаешь раздутость, когда используешь один вариант для локального X сервера, другой -- для удаленного. Unix sockets работают довольно быстро, а команды протокола весьма просты, чтобы на их обработку тратилось огромное время. Локальный сервер работает быстро.

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

>Почему это должно быть причиной создания аналогичного реестру говна в GNU/Linux?<

проприетарные быдлокодеры уже давно притащили это гвоно в виде gconf в линукс.

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

> Зато с программной точки зрения получаем готовую универсальную реализацию.

В каком месте?

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

>SAX так же прочитает весь файл, найдет что тебе нужно, а потом ты всё равно запишешь весь файл обратно на диск...

SAX весь файл в память не грузит. События типа Элемент(XPath) отрыт/Элемент(XPath) закрыт можно в stdout писать. Дальше вполне можно потоково пережевывать перлом/awk и выводить измененный файл.

Absurd ★★★
()

а нельзя сделать, что бы приложение, которое нужно настраивать, типа xorg, предоставляло виртуальную FS типа /proc со своими настройками. а вот другое приложение это хранило в каком угодно хранилище, а третье - следило за синхронизацией настроек, т.е. сам xorg ничего не хранит/следит/загружает и просто говорит какие есть у него настройки.

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

> благодаря этой архитектуре протокол не меняется 11 лет

Протокол не меняется, потому что он - протокол. Вместо него используют другой протокол - vnc или rdp. А иксы не меняются, потому что нет альтернативы имеющейся кодовой базе, а при модели bazaar'а, никаких кардинальных переработок быть не может. Для разнообразия можешь помедетировать, почему разработчики OS/2, BeOS и др. не использовали иксы как основу, хотя включали средства совместимости.

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

> Порадовало с www.reactos.ru

Точку зрения разработчиков ROS я знаю, дискуссии имел. Архитектура X Windows плоха с точки зрения windows разработчика, и только.

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

>SAX весь файл в память не грузит

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

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

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

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

Какие теги? SAX читает файл потоково и дергает колбэки вида тег открыт/свободный текст/комментарий/тег закрыт.

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

Нет, надо в перле (например) гнать все в stdout как есть, за исключением двух тегов c определенным XPath.

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