LINUX.ORG.RU

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

 , ,


0

0

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

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

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

★★★★

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

согласен, я другого и не говорил, НО! всё равно - SAX прочитает весь файл. файл не индексированный, ты не сможешь сместиться на питцот тегов и прочитать с диска только 2 тега. это простой тестовой файл.

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

>гнать все в stdout как есть

и что бы сохранить это ты должен записать всё это барахло на диск.

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

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

и ? c текстовыми файлами как быдто не так...

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

>SAX прочитает весь файл. файл не индексированный, ты не сможешь сместиться на питцот тегов и прочитать с диска только 2 тега. это простой тестовой файл.

Мы сравнивали xml с плоскими текстовыми файлами, которые тоже обычно читают от начала до конца.

>>гнать все в stdout как есть

>и что бы сохранить это ты должен записать всё это барахло на диск.

В /tmp/* файл, а потом переместить на место старого. Типа "транзанкция".

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

>и ? c текстовыми файлами как быдто не так...

точно, и поэтому не нужно менять текстовой xorg.conf на такой же текстовой xml. XML не нужен.

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

>но прочитает его весь.

любой парсер текстовых файлов так будет делать, потому что указывать нужное место "в хедере в байтах от начала" это не по текстовому.

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

>XML не нужен.

унификация парсеров нужна. XML нужен.

в каждой проге свой велосипед изобретать это сакс.

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

>ещё есть StAX

2 my mind можно даже на базе expat сделать замечательный тул для модификации xml-данных из скриптов.

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

структуированная информация без оверхеда который мотребуется в INI:

NodeA.NodeB.NodeC=Something - второй уровернь вложения.

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

>структуированная информация без оверхеда который мотребуется в INI: > >NodeA.NodeB.NodeC=Something - второй уровернь вложения.

Вот такой конфиг точно нужно каждый раз от начала и до конца читать.

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

>унификация парсеров нужна.

Унификация парсеров не нужна, так как делает конфиги избыточными. Основное преимущество существующих текстовых конфигов — возможность дописывать в них с помощью echo и другими простыми средствами без их чтения и разбора.

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

> Основное преимущество существующих текстовых конфигов — возможность дописывать в них с помощью echo и другими простыми средствами без их чтения и разбора.

На "преимущество" это не тянет. Фига с два ты с помощью своего эха воткнешь опцию в нужную секцию xorg.conf'а.

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

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

>возможность дописывать в них с помощью echo и другими простыми средствами без их чтения и разбора.

Чего чего? А EndSection??? echo???

80% народа трындящих тут ни разу не заглядывало в gconf. В качестве XML они представляют сеюе помойку генерируемую MS Office.

Итак если у вас есть гном заходим в ~/.gconf Что мы видим? Где там 1 гиганский XML файл? Нету его. А почему? Да потому, что опции разбиты на множество %gconf.xml кусочков. И это гораздо быстрее чем сборка одного большого Apache Like конфига, не говоря уже о конфигах как в BIND.

Насчет читабельности:

em@linice:~/.gconf/apps/gthumb$ em@linice:~/.gconf/apps/metacity/general$ cat ./%gconf.xml <?xml version="1.0"?> <gconf> <entry name="action_double_click_titlebar" mtime="1196694074" type="string"> <stringvalue>toggle_maximize</stringvalue> </entry> <entry name="auto_raise_delay" mtime="1196434532" type="int" value="1000"> </entry> <entry name="auto_raise" mtime="1196434532" type="bool" value="true"> </entry> <entry name="num_workspaces" mtime="1207210985" type="int" value="6"> </entry> <entry name="theme" mtime="1213109183" type="string"> <stringvalue>Gray</stringvalue> </entry> </gconf>

Вполне читабельно.

Далее речь шла не только о XML, а о ВОЗМОЖНО XML в связке с GConf.

Почему ВОЗМОЖНО подчеркнуто? Да потому, что GConf глубоко перпендикулярно в XML конфиг или в YAML или INI стиль этого конфига.

Для каждого стиля должен быть Бэкэнд. Зато если я отредактирую INI файл вручную мне прийдется как-то уведомлять программу которая читает этот файл об изменениях (господа как??? kill? или в каждой программе ключик?)

А вот если я сделаю:

gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true

даже Vino запустится. Потому, что там GConf у которого триггер на это событие.

Кстати gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true

Уж куда лучше echo "Option true" >> /etc/X11/xorg.conf

Хотяб потому, что у кого-то xorg.conf может лежать в другом месте, а кто-то опечатку в true сделает или вместо >> сделает > и все....

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

Конечно вот так:

<?xml version="1.0"?>
<gconf>
  <entry name="action_double_click_titlebar" mtime="1196694074" type="string">
           <stringvalue>toggle_maximize</stringvalue>
  </entry>
  <entry name="auto_raise_delay" mtime="1196434532" type="int" value="1000">
  </entry>
  <entry name="auto_raise" mtime="1196434532" type="bool" value="true">
  </entry>
  <entry name="num_workspaces" mtime="1207210985" type="int" value="6">
  </entry>
  <entry name="theme" mtime="1213109183" type="string">
            <stringvalue>Gray</stringvalue>
  </entry>
</gconf>


Хотя даже сломанное форматирование будет работать
Тут куча народа не любят питон и в качестве главного аргумента приводят форматирование. А тут когда их любимые конфиги повреждаются при неправильном форматировании им хоть-бы хны

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

>Основное преимущество существующих текстовых конфигов — возможность дописывать в них с помощью echo и другими простыми средствами без их чтения и разбора.

угу, основное преимущество доса - это возможность запускать на 286ом.

ни echo ни 286ые сейчас не нужны. Рулят навороченные интегрированные фреймворки...

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

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

для этого и xml сойдёт.

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