Реестр! Ы!

Т.е. каждый раз сверяться с очередным 100500ым синтаксисом легко, а XML громоздкий…

Парадокс каталогов предлагаете рассмотреть?

>Т.е. каждый раз сверяться с очередным 100500ым синтаксисом легко, а XML громоздкий…
Как будто поверх XML не нужен ещё один синтаксис.

А когда у тебя инит не загрузится, ты бинарный редактор на дискетках подтаскивать будешь? Шли бы вы: всё и так работает. Максимум - это переход на yaml-подобный формат конфигов.

> Единый формат. Одни программы легко меняют конфиги других.

привет вирью

> - Надо переписать всё, что уже написано

В гноме уже давно такой подход

А некоторые используют в конфиге тьюринг-полный язык.

вот и пусть хранят свой адский конфиг в реестре с типом BLOB

> Способ получения у тебя сливается со способом хранения.

Потому что им занимается одна и та же система
Например, есть настройка 'org.myapp.window.size".
Можно спросить registry_get('org.myapp.window.size"), и точно такой же командой можно записать его registry_set('org.myapp.window.size", value). А какая уж будет реализация этого действия - на совести реализации драйвера реестра для каждого конкретного дистрибутива.

Уважаемый ls-h, вы мне напишите sed, diff, mercurial и прочее для вашего реестра? или вы меня вынуждаете юзать ваш недоделанный regedit?

Ваша идея просто глупа. Аргумент «не найти конфиг» - болезнь. Ламерство называется. вы что-нибудь слышали про man и info страницы? нет? ставьте семёрочку и нее пишите здесь бреда.

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

файл я могу найти СТАНДАРТНОЙ утилитой поиска. А как искать ключи в вашем реестре?

Я знаю как вы сделаете:

параметр=значение

Причём проиндексируете по параметру.И поиск будет по параметру. А как искать по значению?! Не нужно?

А мне - нужно.

> Почему когда речь заходит о конфигах и реестре, то oldschool'ные (а может и не oldschool'ные, а просто тролли) *nix'оиды посылают лечиться приверженцев реестра и других БД-образных конфигохранилищь?

Единообразно, значит единый новый API. Значит будут лентяи и неосиляторы, из-за которых что-то будет ломаться. Проходили :)

То, что в винде реестр представляет собой неудобоваримое нечто еще не означает что нельзя сделать хорошо.

В том, что реестр — запутанное месиво, виноваты не столько авторы Windows, сколько программисты, продукты жизнедеятельности которых пишут в реестр. Можно написать сколь угодно хороший API или синтаксис для этого реестра, но всё равно найдутся те, кто применит их не по назначению. Есть опасения, что таких опять будет большинство :)

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

Опыт показывает, что маленьким его сделать не смогут.

Если в этом, так называемом реестре, сделать схемы, то строить GUI можно будет быстро и просто, гораздо проще чем писать парсер конфига.

Существует множество хороших библиотек для работы с конфигами. Но большинство программистов пишут что-то своё. Иногда их что-то не устраивает, часто просто лень :) Думаешь, будет много желающих изучать твои схемы?

Перейти на что-то единое можно только заставить. Как это сделали в Гноме. Они просто могут не принимать программы не соответствующие требованиям. Результат — куча недокументированных опций, известных только авторам программ. В более традиционных конфигах эти опции обычно перечислялись в виде комментариев.

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

Итого. Неспециалист предлагает всё переделать, потратить кучу времени на изучение чего-то очень нового, но малополезного, приобрести кучу сложностей без ощутимых выгод. в случае отказа увеличивает настойчивость. Разумеется, уже возникла привычка встречать такие предложения в штыки :)

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

Те программы, с которыми я ковырялся, обычно имели штук до 8 мест, где могут быть их конфиги. И жёсткий порядок в котором их читать. Обычно дистрибутив использовал только 2-3 места.

Найти нужный файл, перерыв ~, /etc, /usr и /opt не сложнее, чем нужную ветку реестра. Зато текстовые файлы-конфиги реже называют по UUID :)

> Вся проблема в том, что ты пытаешься работать с БД/файликами, а не конкретно с информацией.

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

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

Можно пример запроса к конфигам, недостижимого при помощи find-grep-sed?

Я не спорю, БД могут больше. Но нужны ли эти возможности здесь?

Выложить кусок БД ты можешь очень просто - сформировав нужный запрос и получив на выходе нужную тебе информацию.

Лишняя сущность — каждый раз нужно придумывать запрос :)

> нарисуйте мне гуй, с помощью которого можно наконфигурять, например, такое:

Дельфи же! С дополнительным тулбаром с комбо-боксами операторов, функций и переменных. Чтобы их можно было дрэгать и дропать на форму.

Только никому не рассказывайте, чтобы кто-нибудь такое взаправду не сделал :)

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

Накалываю путь шилом. По шилу стучу молотком. То есть добавляю предварительный вызов молотка с параметром «шило» :)

> если все программы будут хранить конфиги в ямле, причем этот конфиг можно будет однозначно получить независимым от дистрибутива и ОС способом - я согласен)

Вайн пытался сделать большой реестр, как в Windows, но сделать его чисто текстовым. Выглядит как разумный компромисс. Первые лет 15 объёмы были невелики, работало приемлемо. Сейчас реестр разросся, читать его каждый раз стало долго, поэтому от текстового реестра решили отказаться.

И это будет с любым централизованным хранилищем конфигураций в достаточно сложной системе.

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

В общем, да. Система текстовых конфигов децентрализованнее и избыточнее сжатого бинарного реестра. Поэтому надёжнее и легче восстанавливать.

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

Где взять к ней в комплекте программистов, её уже осиливших? У тех, что есть, и так сроки горят. Они освоят пару вызовов и примутся мусорить в БД. Не потому, что быдлокодеры, а потому, что у них есть работа, которая лично им важнее унификации конфигов.

И мы придём к необходимости чистилок реестра под линукс :)

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

Как? Взять все глобальные переменные и записать их в базу данных? Глобальные переменные тоже считаются злом. Да и может быть недостаточно сохранить только их. Сохранять и все локальные тоже? Поздравляю, реестр уже разбух до сотен мегабайт от одного браузера :)

Конфиги необходимо вдумчиво проектировать. И по сравнению с этим нет большой разницы, пропускать их через движок БД, или парсер-генератор ini или XML.

> Где ты увидел: 1) глючный, 2) мастдай ?

Это единственный хорошо известный случай массового применения чего-либо похожего на предлагаемое. Имхо, большинство глюков и косяков — от программистов не осиливших API, но их всегда большинство.

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

Это как? Вся работа с компом — читать надпись на экране «Тебе уже за^Wхорошо» ? Разве что так. И то может понадобиться поменять провайдера. Или подстроить цвет. Или сменить монитор.

> зачем ты их считаешь?

По работе имею дело с программой, которая создаёт даже не 100, а всего порядка 40-50 веток реестра. Пишется и поддерживается коллективом программистов. Теоретически программа может работать под простым пользователем. Практически этот коллектив за 10 лет не смог разобраться с правами на все эти ветки, поэтому программа требует прав админа.

И причина такой путаницы — не в глупости программистов, а в плохой координации их работы. Учитывая, сколько в линуксе «базарных» проектов, с введением реестра проблема станет ещё острее, чем для оффтопика.

> можно не одну таблицу использовать, а две, три или десять, лол. Если это поможет тебе навести порядок.

Кто не способен навести порядок в одной таблице, тот тремя положение только усугубит.

> Нафига там транзакции и параллельность?

Видел как оффтопик грузится? Каждая программа по очереди ищет свои ветки в реестре, читает их, что-то туда пишет. В результате, если в автозапуске много программ, процессор первые минуты после появления десктопа может оставаться загруженным на 100%.

Или если у программы много информации хранится в реестре. Когда запускается Fine Reader 9, вся система замирает. Особенно под вайном, где реестр работает заметно медленнее.

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

> а в реестре можно раздавать права на разные ветки

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

>Каждая программа по очереди ищет свои ветки в реестре, читает их, что-то туда пишет.

по очереди

что, серьёзно? да быть не может.

пусть хранят свой адский конфиг в реестре с типом BLOB

У нас уже есть такой реестр. /etc имя ему.

Может лучше сотрёшь свой комментарий от греха подальше?

А это ничего, что есть не только линукс, но и OpenBSD, FreeBSD, Solaris, Windows, Hurd, MacOS и много всяких других ОС?

Текстовый конфиг прочтется и распарсится на всех, правится на любой и инсталируется на любую другую, поэтмоу он и используется практически во всех случаях, когда программа работает хотя бы на двух из указанных платформ. Java, VirtualBox, Apache, Squid, Pidgin, Postgres, MySQL, PHP... Продолжишь сам?

Угу. И каждый надо валидировать и парсить по своему. Было бы соглашение по структурированию конфигов хотя бы, было бы ок. Ну и опять же. Права доступа не слишком гибки, синхронизация секций итд.

Ящитаю интерфейс к настройкам через LDAP был бы ок :]

> Текстовый конфиг прочтется и распарсится на всех

распарсится на всех
распарсится

щито?

но-даши намекает на универсальность, независимость от ОС синтаксического анализа.

файл я могу найти СТАНДАРТНОЙ утилитой поиска. А как искать ключи в вашем реестре?

Стандартной утилитой поиска в реестре. То, что ты написал слово капсом не делает его ужасающим аргументом.

Причём проиндексируете по параметру.И поиск будет по параметру. А как искать по значению?! Не нужно?

Продолжай спорить с собой, я понаблюдаю.

На костыльность и велосипедность синтаксического анализа для каждого следующего приложения вне зависимости от ОС. ок. понимаю

Найти нужный файл, перерыв ~, /etc, /usr и /opt не сложнее, чем нужную ветку реестра

А как ты определишь, какой файл тебе нужен?

Зато текстовые файлы-конфиги реже называют по UUID

У меня тут Джумла неподалеку стоит, так я вообще не знаю, как там таблички называются. Это не мешает мне быстро находить нужные данные, которые в ней хранятся.

ок. понимаю

А я тебя --- нет. Изволь оформить свой взгляд в виде кратких тезисов.

А как ты определишь, какой файл тебе нужен?

попробуй почитать man на пакетный менеджер твоего дистрибутива. там это есть.

> Может лучше сотрёшь свой комментарий от греха подальше?

После твоего ответа на него уже не могу :)

> быстрый бинарный поиск всего нужного вконфиге

Когда все лежит на местах, поиск не нужен.

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

Как это?

Можно пример запроса к конфигам, недостижимого при помощи find-grep-sed?

Любой запрос, не основанный на выборке значений по стандартным флагам ФС. Можно, например, искать информацию по тегам.

Я не спорю, БД могут больше. Но нужны ли эти возможности здесь?

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

Лишняя сущность — каждый раз нужно придумывать запрос :)

Никакая это не лишняя сущность. С тем же успехом лишней сущностью могут быть и разные ключики и параметры к find-grep-sed.

> что, серьёзно?

А что, все сразу? Не успел дописаться файл реестра, как его начинает корёжить от следующей команды записи в реестр?

Стандартной утилитой поиска в реестре

Кастую стандартный sed реестра, стандартный diff реестра, стандартный patch реестра, стандартную VCS реестра etc.

Что непонятного в «велосипедность синтаксического анализа для каждого следующего приложения»?

Попробуй написать парсер конфигурационных файлов named, и извлечь им информацию из конфигурационного файла postfix.

Если для xml формата , то diff реестра, стандартный patch :

http://diffxml.sourceforge.net/

а sed и нафиг не нужен при разнообразии dom и xslt примочках.
И вообще, весь тред сплошная феерическая стена плача незнаек web-технологий.))

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

Как это?

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

Реестр больше похож на текстовый файл, сжатый LZ, поэтому его не надо :)

Можно пример запроса к конфигам, недостижимого при помощи find-grep-sed?

Любой запрос, не основанный на выборке значений по стандартным флагам ФС.

Да? Пример: grep -ri eth0 /etc

Флаги ФС не используются, выдаст все упоминания eth0

Можно, например, искать информацию по тегам.

Что ты имеешь в виду под «тегами»?

Я не спорю, БД могут больше. Но нужны ли эти возможности здесь?

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

Подавляющее большинство файлов конфигов либо имеют то же имя, что и программа, либо лежат в директории с тем же именем. Не можешь запомнить и это?

А помнить значения каких-то полей БД всё равно придётся.

Лишняя сущность — каждый раз нужно придумывать запрос :)

Никакая это не лишняя сущность. С тем же успехом лишней сущностью могут быть и разные ключики и параметры к find-grep-sed.

Разумное возражение. Имхо, людей, которые что-то делают со stdin-stdout и регулярными выражениями всё же больше, чем регулярно работающих с SQL. А те, кто знаком со вторым обычно уже знают первое. Что касается noSQL: там надо каждую базу изучать заново, или есть какой-то стандарт?

Не понимаю, почему темы об унификации доступа к конфигурационным данным всегда скатываются к реестру. Но. Тем не менее. Есть стандартная утилита regedit, которая экспортирует и импортирует реестр в ini' подобный файл. Внезапно. С которым ты можешь это всё проделывать твоими «стандартными» штуками. Где у /etc/ стандартные точки восстановления кстати, а? )

> А те, кто знаком со вторым обычно уже знают первое. Что касается noSQL: там надо каждую базу изучать заново, или есть какой-то стандарт?

Вах , я так и не дождусь упоминания debconf у местных «мракобесов» ))

попробуй почитать man на пакетный менеджер твоего дистрибутива

У него 234 пакетных менеджера Setup.exe, и ни в одном список файлов получить не получается :-)

Где у /etc/ стандартные точки восстановления кстати, а?

/opt/backup, естественно. Зовутся очень понятно, кстати - etc_2010-12-19.tar.bz2, etc_2010-12-20.tar.bz2, etc_2010-12-21.tar.bz2 и так далее. Или вас с этим попоболь возникла???

Что непонятного в слове «стандартные»? :]

avatar@AliSo ~ % ls -l /opt/backup
ls: невозможно получить доступ к /opt/backup: Нет такого файла или каталога

oh shi~~