Реестр! Ы!

Так вот деточки, послушайте старого дядю... %-)))

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

Рассказую.... через много лет товарищи разработчики решат, что нужно делать очень правильно, а именно

XML->SQL->Binary Database file...

Да будет так!

и это говорит нытик неосиливший найти конфиги в своём дистре

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

уйди!
пока по-хорошему прошу!

воот, в тред вошли люди с правильным состоянием сознания =)

>я люто бешено плюсую систему, в которой конфиги никто не правит за ненадобностью.
таких НЕ СУЩЕСТВУЕТ!
впринципе!
иначе кастую пруф на хомпагу!
и да - ЛЮБАЯ настройка - это правка конфига!
через как и куда править - не суть!

Хотя главный демон не нужен. Я его не знаю нафига написал...

Чем конфиг в арче не реестр? Там ведь конфиги всего в одном конфиг файле, и сеть, и прочая фигня?

Читать Реймонда по два часа вечером натощак.

>облако серверов настроил, а репликацию не освоил. Бида. А я думал что мы здесь про десктоп говорим... хм
Какой десктоп на линуксе то? Да и репликацию я освоил, но на каждом сервере поднимать базу и репликацию(пусть и скриптом) ради нескольких десятков килобайт файлов кажется немного оверхедом.

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

Хватит тут хаскеллить и факториалить. Вот http://pastebin.com/QTig3Ev0 маленький конфиг, приведите пример структуры таблицы.

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

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

Какие схемы? Какое равноправие? Зачем реестр, если там тоже perl и sed? Никакой конкретики.

- Легко связать со справкой даже для текстового интерфейса (см. пред пункт)

Там ничего не понятно.

- Единый формат.

ПЛОХАЯ идея.

Вот конкретный маленький пример простого конфига из 23 строк. Приведите хотя-бы примерную оптимальную структуру БД.

понятия не имею. Чесна. По мне так все эти конфиги - зло, и они должны генериться автоматически на основе текущего состояния программы. Можно в какую-нибудь no-sql бд, если так уж тебя пугают таблички. А что и как в этой бд будет храниться - пусть бд сама и решает. Мое дело в нее объекты сохранить и получить назад когда потребуется.

>они должны генериться автоматически на основе текущего состояния программы

Тогда что станет с конфигами, если программа упадёт?)

но на каждом сервере поднимать базу и репликацию(пусть и скриптом) ради нескольких десятков килобайт файлов кажется немного оверхедом.

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

>понятия не имею. Чесна. По мне так все эти конфиги - зло, и они должны генериться автоматически на основе текущего состояния программы. Можно в какую-нибудь no-sql бд, если так уж тебя пугают таблички. А что и как в этой бд будет храниться - пусть бд сама и решает. Мое дело в нее объекты сохранить и получить назад когда потребуется.
Вооот, мы уже на верном пути. И чем сохранение объектов в no-sql базу отличается от сериализации объектов в формате YAML на диск?

Хранить все пароли на бумажке, приклеенной к монитору :)

>Вот http://pastebin.com/QTig3Ev0 маленький конфиг, приведите пример структуры таблицы.

Можно так и хранить плэйн-текст для сложных стурктур...

Тогда что станет с конфигами, если программа упадёт?)

если в момент падения прога писала что-то в конфиг, то транзакция отменяется, и конфиг возвращается назад на момент до начала транзакции. Если не писала - не происходит ничего, прога перезапускается и читает что там в конфиге понаписано.

И чем сохранение объектов в no-sql базу отличается от сериализации объектов в формате YAML на диск?

ничем. Кроме того что любители текстовых конфигов взвоют, что им сериализованный yaml неудобно править текстовым редактором.

>Тогда что станет с конфигами, если программа упадёт?)

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

Ты просто так написал, как будто бы никакой операции сохранения и нет. Как в ФантомОС)

Черт с ним с реестром и БД. Главное, что большинство поделок работает по схеме «считать конфиг - начать работу - ... - завершить работу - сохранить конфиг». Благодаря этому, в 2010 году видим чудеса типа сбивания всех настроек из-за падения (которое между прочим не только самой программой вызвано может быть). Слово «надежность» многие похоже не слышали.

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

То есть, он будет выглядеть как vim, а не как emacs. Щас начнется :-)

Можно сделать текстовый интерфейс на уровне файловой системы (Например через FUSE или как часть ядра. Oldschool'ные тролли «Ааа... жуть... Реестр в ядре... Иди на семерочку!»). Пользователь сможет править конфиг как текст, программы будут работать через библиотеку, храниться может это все очень по-разному. Более того, можно будет сделать текстовый интерфейс с разным сиснтаксисом.

Идите в ж#пу. Нет ничего лучше текста и магомед пророк его. Я посмотрю как вы на форум будете выкладывать свой бинарный конфиг на форум в случае проблем.

На удаленном сервере, система обычно крутится годами, и ее админит куча приходящих-уходящих людей... Отсюда - revision history конфига, а так же комментарии в оном часто просто бесценны, и поэтому любой формат идет в лес.

Ты какую, вообще проблему решить-то пытаешься? Тебе не написать парсер конфигов? Есть куча библиотек, под любой мыслимый синтаксис.

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

>И чем сохранение объектов в no-sql базу отличается от сериализации объектов в формате YAML на диск?

Чем это будет принципиально отличаться от нынешних конфигов?

Лирическое отступление: недавно у родителей комп в выньХП был заблокирован всплывающим порнобаннером. А я как семь лет назад на линух перешёл, так с виндой дела и не имел. Забыл уже всё. Первой мыслью линуксоида было загрузиться как-нибудь, разобраться с системой инициализации и вручную удалить зловредный процесс. Нихрена не получилось, потому что сложно всё очень. А вот разобраться с SysV или bsd-like init'ом в нормальной оси --- как два байта переслать.

Отсюда мораль: всё должно быть сделано тупо и просто. А вы с вашими бд-реестрами в ядре ступайте в анус ничистой собаки.

>Можно так и хранить плэйн-текст для сложных стурктур...
Таким образом вместо написания парсера, мы пишем клиент к БД и парсер.

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

синхронной или асинхронной? И где конфигурацию репликации хранить? Тоже в реплицируемой бд?

>Чем это будет принципиально отличаться от нынешних конфигов?
Ничем, это в сущности они и есть.

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

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

А что, сейчас поиск медленный? Приведите ссылку на то, чтобы кто-то где-то имел проблемы со *скоростью поиска в конфиге* !!!???!!

об этих деталях можно подумать позднее.

1) По любому придётся писать слой совместимости. Как вариант, виртуальная ФС для /etc, где всё в классическиих форматах. Возможность залезть текстовым редактором в конфиг и поправить что-то должна быть всегда.

2) Реестр как в винде - говно. По сути, просто бинарная база таблиц. Параметр и число/строка. При этом монструозный интерфейс обращения к нему располагает превращать реестр в помойку. Взять винду - там часто хранится то, что должно лежать в /var.

3) Мощная БД слишком сложна для конфигов. Серия текстовых замен это быстрее чем вкуривать реляционные отношения. Представьте, как например будет выглядеть конфиг апача.

4) Подразумевается, что конфиг в /etc это нечто либо не требующее вмешательства пользователя (подавляющее большинство программ). Или, как в крутых серверных программах, всё документировано. При этом можно (например, в ejabberd) не вникая поменять true на false пару раз и прописать вместо hostname.domain требуемый домен, чтобы всё заработало.

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

6) Универсальная модель «для всего» всегда слишком громоздко и неповоротливо. Экономия времени разработчика весьма сомнительная, многие предпочтут и дальше делать конфиги в таком формате, в каком программе удобнее с ней работать.

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

> несколько пользователей одновременно правят несколько взаимосвязанных конфигов нескольких программ. На файлах это кошмар.

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

> Обычно выдвигается аргумент типа «Текстовый конфиг можно править текстовым редактором». А что бинарный нельзя?

Вообще-то нельзя.

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

Этот маленький редактор выплюнет в лучшем случае XML. Это единственное, чем можно объединить множество сложных вариантов конфига.

НИКТО не будет редактировать XML.

если все программы будут хранить конфиги в ямле

Осталось уговорить всех программистов. Займись этим.

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

При портировании между дистрибутивами и ОС есть гораздо более серьёзные проблемы, учесть несколько путей конфига - мелочь.

несколько пользователей одновременно правят несколько взаимосвязанных конфигов нескольких программ.

ничего страшного, т.к. изменение в

 /home/masha/.coolprogramrc

 /home/pasha/.coolprogramrc

А по делу, объясните мне недалёкому, чем текстовые конфиги отличаются от реестра.

Понятно, что про бинарники ТС дал маху, но оставим это на его совести.

Вот давайте подойдём с такой стороны - если я просто в FS упорядочу конфиги с помощью дерева каталогов, типа /etc - корень, /etc/sys - системные настройки, /etc/home - точка монтирования ветви пользователя физически лежащей в /home/etc, /etc/hrd - всё что касается железа и etc.. :)

Вплоть до листьев типа /etc/home/gnome/apps/MyCoolApp/main.conf.

ФС при этом даёт нам кучу возможностей по представлениям с помощью тех же симлинков.

Например мы можем иметь /etc/apps/MyCoolApp/home и /etc/apps/MyCoolApp/share которые будут симлинками (ну или наоборот) на /etc/home/gnome/apps/MyCoolApp и /etc/share/gnome/apps/MyCoolApp соответственно.

Так вот - это уже реестр или ещё текстовые конфиги?

Вот, mono идею подкинул. Сделать прослойку, которая представляет конфиг в универсальном формате. А откуда брать конфиги и как парсить - свалить на прослойку. Возможно, именно сделано в GSettings, но достоверно проверить не удалось.

портирование не нужно

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

выборку таких параметров можно, кстате, также встроить в тот самый «реестр». в ветку HKEY_CURRENT_CONFIG/Distro/Generic oh shi~!!!

или что, есть какие-то вещи, которые так принципиально нельзя получить?

Кто-нибудь уже сказал, что конфиги должны быть в XML?

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

Способ получения у тебя сливается со способом хранения. Посмотри мой пост чуть выше.

Кажется я опоздал. :D

А что, нормальный человек станет редактировать XML-конфиги?

А что, нормальный человек станет редактировать *-конфиги?

>Кто-нибудь уже сказал, что конфиги должны быть в XML?
Зачем XML если есть YAML?

Почему ты это спрашиваешь у меня?

Синтаксис *-конфигов минимален и в нём легко разобраться. Синтаксис XML громоздкий и в нём легко запутаться.