А как по скорости разбор бооольшого ini файла?

А зачем тут бооольшие?

$ ls -ksS ./.kde/share/config/* | head -4
48 ./.kde/share/config/katesyntaxhighlightingrc
36 ./.kde/share/config/khotkeysrc
36 ./.kde/share/config/katemoderc
24 ./.kde/share/config/kglobalshortcutsrc

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

в GKeyFile подобные штучки есть

>Что-то вроде JSON. Тривиальные списочки, словарики и т.п. плоским файлом нормально не реализуешь

Словарики это уже не конфиги. И не сравнивал скорость обработки ini, json и xml, но насколько первый отличается по читаемости — говорить излишне, а это весомый плюс.

Введут. физический.

потом если что руками не поправишь.

прийдёться сносить хором настройки всех приложений.

включил экпериментальную фичу в реестре - снёс все настройки.

как-то я давно включил composite в метасити на посмотреть, с nvidia дровами - гном пришел в негодность, стер конфиг от метасити заработало, скоро будут стругать консольные утилиты для исправления искривлений в конфигурации.

З.Ы. комманды а-ля dconf --потри-ключь apps/chevoto/prefs/kluch не предлагать.

Любой традиционный плоский конфиг уже словарик в тривиальном виде. Вопрос в том, чтобы уровней было больше при необходиости. Смотри хотя бы конфиги давно известных сервисов типа bind и dhcpd.

Скорость обработки сильно упасть может разве что у xml, для остального это приемлемая мелочь.

но насколько первый отличается по читаемости — говорить излишне, а это весомый плюс.

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

А чем тебя не устраивает dconf --потри-ключь apps/chevoto/prefs/kluch ?

Любой традиционный плоский конфиг уже словарик в тривиальном виде

Тривиальные списочки, словарики и т.п. плоским файлом нормально не реализуешь

Э? ;)

Если надо серьезный словарь, то ini неудобен, согласен. Но, повторюсь, это уже не конфиг.

Вопрос в том, чтобы уровней было больше при необходиости. Смотри хотя бы конфиги давно известных сервисов типа bind и dhcpd.

Эта необходимость есть далеко не всегда. В /etc абсолютное большинство конфигов таки традиционного формата, а не json с xml.

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

$ cat ./.kde/share/config/knotifyrc
[Misc]
LastConfiguredApp=Konsole

[Phonon::AudioOutput]
KNotify_Volume=1

Убожественная читабельность, говоришь? Как раз нормальная, простая структура. Усложнить — ухудшится и вид.

Непонятное в gconf

Вот, скажем, есть директория ~/.gconf/apps/gedit-2/, в которой gedit хранит настройки через gconf.

Но ведь еще есть файл ~/.gnome2/gedit/gedit-2, в котором gedit хранит еще какие-то настройки (размеры окна и т.п.) в формате ini.

Спрашивается, нахрена? Если что, в /etc/make.conf у меня всегда было -gnome -kde.

Алсо, в /etc/gconf/2/path есть строчка вида «xml:readwrite:$(HOME)/.gconf». Значит ли это, что xml можно заменить на другой, православный backend? Засунуть, скажем, «ini:readwrite:$(HOME)/.gconf» в ~/.gconf.path, и тогда в ~/.gconf все будет православно, без тысяч директорий с файлом %gconf.xml?

Если приложение тормозит из-за разбора настроек, то надо менять что-то в приложении, а не изобретать очередной реестр.

> Получается в чистом виде бинарный виндовый реестр со своим сервисом чтения бинарного блоба.

Binary XML придумали даже не вчера

> Если надо серьезный словарь, то ini неудобен, согласен. Но, повторюсь, это уже не конфиг.

Конфиги бинда, например, смотрел? посмотри

В /etc абсолютное большинство конфигов таки традиционного формата, а не json с xml.

Традиционный это какой? Единственный там в какой-то степени традиционный формат это .sh, который не совсем конфиг. Всё остальное это разношорстные форматы многие из которых структурные. Нет там абсолютного большинства.

А тут не из-за тормозов всё меняют. Здесь просто хотят сделать один API для разных систем. Никто не мешает например сделать backend для хранения настроек в xfceшном конфиге и т.д.

> ...оно разрастется еще похлеще виндовых 50 методов

Да ладно вам напраслиной срать! Если не считать туповатых «OpenKey», то враппером всё уместится в три вызова: List, Read, Write.

Тривиальные списочки, словарики и т.п. плоским файлом нормально не реализуешь.

Надо полагать 'аффтар' пробовал и у него не получилось? Тогда как у более-менее адекватных товарищей лет за дцать до появления xml всё это уже было в ini не говоря уже о S-Expression и YAML.

Эва как оно, оказывается у вас в UNIX-е. Смогли! А мы тут в GNU/Linux нет. Как с сокетами и shm столкнулись так и обламаськи вышли с системными вызовами - пошли сотни их.

>Никто не мешает например сделать backend для хранения настроек в xfceшном конфиге и т.д.

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

find /etc -type f -name \*.sh 2> /dev/null | wc -l

17

find /etc -type f 2> /dev/null | wc -l

1502

и таки все вменяемые в ini!

Но всё таки, последнее время /etc обрастает xml-говном. Скоро в лялехе без специальных утилит нельзя будет конфиги править.

> прискорбно..... значит будем использовать либо XFCE, либо LXDE.... а для себя я давно выбрал OpenBox + всякие приблуды.

Не поможет, Гномовская конфиг-система используется многими GTK-плюснутыми аппликациями.

это и сейчас есть.

man awesome и man xmomad

Если бы ещё там был просто XML, так они ж его как язык программрования используют… Нет, конечно, такие есть, но делать на них «конфиги» это какой-то изощрённый вид мазохизма.

ну, да, нечитающие доки (в данном случае, по ASN.1) - хроническая беда человечества, с древних греков начиная

А впрочем, можно ведь сделать это в виде какого-нибудь dconffs и монтировать, например, в /etc/dconf. В итоге работать будет быстро, а Ъ получат свои конфиги в виде файликов. Вуаля! Вот он какой, unixway.

>Конфиги бинда, например, смотрел? посмотри

Нет у меня самого бинда, только utils и libs. Что это меняет принципиально?

Традиционный это какой?

squid, lighttpd, mplayer.. Мелкие различия, если есть, несущественны, принцип-то общий.

Всё остальное это разношорстные форматы

Мы точно об одном и том же?

Ага, причё в том формате, каком они захотят....

>Но всё таки, последнее время /etc обрастает xml-говном. Скоро в лялехе без специальных утилит нельзя будет конфиги править.

XML там это dbus, hal, udev(не совсем xml, но все же), ISC-products (named, dhcpd, etc), font-config, xorg+hal. Все остальное - стандарные ini-style. Тем не менее разницы нет xml или ini, IMHO, и то и другое а) читабельно, б) редактируемое в любимом vim. И да, манулы от этого читать всеравно нужно.

> А чем тебя не устраивает dconf --потри-ключь apps/chevoto/prefs/kluch ?

а если я не помню что за ключ?

тогда мне нужен ещё dconf-grep, dconf-ls и т.д.

Пора валить с этого линукса.

Хотя проще написать backend

Ну будет что-то типа dconftool --list | greo key

И чем это плохо?

Помнится, была такая идея - файловая система как база данных. Причем пропихивала идею MS. Так что это, скорее, microsoftway.

И да. Если приложение следит за конфигом и вы там что-нить не то поменяете? Что будет?

А оно нужно?

> ISC-products (named, dhcpd, etc),

О ужас, с каких это пор оно стало в XML ?

а) читабельно

4.2

б) редактируемое в любимом vim.

ага, и бинарники в vim тоже можно редактировать

vasily_pupkin> Когда они уже закончат выпендриваться, и просто будут хранить все в Windows Registry? :]

fixed

>> а) читабельно

4.2

4.2 на ваше 4.2!:) XML читать можно, не очень удобно, но можно! А вот бинарный формат, без спец софта под этот формат заточеного, не прочитаешь и не поправишь.

А вообще при таком раскладе гномоводам придётся переписывать чистилку реестра. Существующая поддерживает только gconf.

> И да. Если приложение следит за конфигом и вы там что-нить не то поменяете? Что будет?

отвалиться приложение.

так можно поменять не так и в спец редакторе.

Ну слава не знаю кому, но hal из Xorg попёрли. Двумя аргументами меньше. Любителям стандартизованности читать ABNF до просветления. Да да да, не вы первые на планете текие все умные. Кому западло ABNF могут и ASN.1 глянуть.

Гнать такие приложения ссаными тряпками. Нехер до команды лезть в дела пользователя.

> А вообще при таком раскладе гномоводам придётся переписывать чистилку реестра. Существующая поддерживает только gconf.

так сейчас реестра физически нет. он виртуальный.

а один бинарный файл прийдётся чистить.

>XML читать можно, не очень удобно, но можно! А вот бинарный формат, без спец софта под этот формат заточеного, не прочитаешь и не поправишь.

дело говоришь :-)

Если один параметр, то ладно. А если нарушен синтаксис?

Очень кстати напомнили мне про tvtime. Очень она любит не в своё дело соваться. приходится на эти ваши xml chmod 0444 ставить

Ага сейчас вам расскажут про vfs dd и прямой доступ к разделу HDD которым вы же не пользуетесь.

>Ну слава не знаю кому, но hal из Xorg попёрли. Двумя аргументами меньше. Любителям стандартизованности читать ABNF до просветления. Да да да, не вы первые на планете текие все умные. Кому западло ABNF могут и ASN.1 глянуть.

Ты видел конфиги нового DeviceKit? Тот же xml... Насчет ASN.1, ну и кто это использует? Разве только LDAP да SNMP, больше к сожалению не встречал. Не дураки ведь если не прикрутили раньше все конфиги к LDAP (я только «за»).

Виртуальщики долбанные. Своими абстракциями затрахали. Не успокоятся пока не дойдут в своих абстракциях до вакуума. VFS и так уже абстрактна - пользуйтесь! У всего ж есть предел. Не надо до маразма доводить. Удобно должно быть только пользователю, программка перебъётся. Она быстрее думает. и себе xml из ini как-нибудь выкрутит, если ей надо. Мне же НЕ НАДО! И бинаря этого НЕ НАДО!

Пожалуйста, админьте свой локалхост, не отвлекайтесь. Вам оно точно не надо.

>ЗЫ интерпретируемо-компилируемые конфиги ждут нас в будующем...

sendmail?

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