Здравствуйте, Cyberax, Вы писали:
C>Простите, моя работа — это не ходить и настраивать Linux'ы. Моя работы — C>писать программы, так что без работы я не останусь.
Вот именно. Ваша работа это писать программы. А вот моя работа — это эксплуатация этих самых программ. Не только и не столько линуксов и юниксов, но и их в том числе. И вот что мне видно из моего окопа.
Есть два класса ситуаций с хранением конфигов:
1) когда мне пофигу в каком формате хранится конфиг, пример: мой сотовый телефон — я настраиваю его через меню и меня совершенно не заботит, какая неонка у него внутре;
2) когда текстовый конфиг в отдельном файле предпочтительнее;
Ситуация, когда я бы предпочел конструкцию с бинарным, а уж тем более монолитным конфигом, противоречит всему моему опыту.
Текстовый конфиг хорош тем, что он, как ни тавтологично это звучит, текстовый. Это значит, что с конфигом можно поступать как с тестом. В нем можно grep'ать, его можно diff'ать, его можно положить в source management system, его легко генерить с помощью, скажем, перла. Сама по себе текстовость дает конфигу массу полезных свойств. Автоматически, просто в силу его текстовости, так сказать, в подарок, и без дополнительных усилий со стороны вендора.
Что касается файловой системы и конфигов, то хранение отдельных конфигов в отдельных файлах, это, натурально, blessing. Пусть нам надо передвинуть приложение "брамбрулятор(tm)" с тазика на тазик. В большинстве случаев надо просто скопировать конфиг /etc/brambulator.conf и все. С "базой данных настроек" будут глупые прыжки и ужимки. Пусть у нас есть high availability: два тазика, на которых крутятся одинаковые брамбруляторы и failover между ними. Естественно, нам надо, чтобы конфиги были идентичными. Обеспечить идентичность файлов /etc/brаmbrulator.conf на двух машинах куда проще, чем (*OMFG*) ветвей реестра.
Нет, конечно, эти все вопросы так или иначе решаются. И я, черт бы их всех побрал, умею их решать — мне за это деньги платят. Большие. Но, чесслово, моя жизнь была бы куда проще, если б конфиги были отдельными текстовыми файлами.
Дальше. Есть такое слово "ремонтопригодность". Слышали когда-нибудь? Важное свойство, между прочим. Вкратце, "ремонтопригодный" значит "если сломалось, можно залезть внутрь и починить", а "неремонтопригодный" означает "если сломалось, то пиши пропало, неси на помойку, чтобы не загромождать жизненное пространство". Так вот, конфиг, который я не могу починить vi'ем (а то и ed'ом), ремонтопригодным не считается и для реальной жизни не пригоден.
Я все понимаю. Красивый API, строгая "инкапсуляция", "ортогональность" и "абстракции" — это все очень хорошо. Но с чего взяли, что нас, ваших пользователей, это е^Hволнует? Нет у нас такой задачи про "инкасуляцию конфигурации". Нету, понимаете? Это Вы сами себе проблему придумали и ее теперь ее решаете. Пожалуйста, уж Вам это доставляет удовольствие. Только ее не за наш счет, ок? Все эти реестры, gconf'ы и прочая дребедень, совершенно непригодная к эксплуатации, — это продукт программистского отрыва от реальности.
Вот такой у меня для Вас наш сисадминский feedback.
А почему вы спрашиваете,
> Текстовый конфиг хорош тем, что он, как ни тавтологично это звучит, текстовый. <...> Вот такой у меня для Вас наш сисадминский feedback.
Ух! Здорово написал. В предпочтительности текстовых конфигов согласен. Вопрос такой: как ты относишься к выбору между XML, INI-подобными файлами и custom formats?
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Вопрос такой: как ты относишься к выбору между XML, INI-подобными файлами и custom formats?
К XML'ю для конфигов я отношусь скептически, все-таки XML весьма условно human readable и практически не human writable — уж больно многословен. Что касается INI-style vs. все остальное, то тут у меня явных предпочтений нет. Главное, чтобы "костюмчик сидел" — чтобы язык конфига был адекватен задаче. В простых случаях INI будет достачно, в случаях посложней, должен окупиться собственный формат.
А почему вы спрашиваете wrote:
> C>Простите, моя работа — это не ходить и настраивать Linux'ы. Моя > работы — > C>писать программы, так что без работы я не останусь. > Вот именно. Ваша работа это писать программы. А вот моя работа — это > эксплуатация этих самых программ. Не только и не столько линуксов и > юниксов, но и их в том числе. И вот что мне видно из моего окопа.
Как всегда, пришли сисадмины и все испортили
> Есть два класса ситуаций с хранением конфигов: > 1) когда мне пофигу в каком формате хранится конфиг, пример: мой > сотовый телефон — я настраиваю его через меню и меня совершенно не > заботит, какая неонка у него внутре;
Ну и так, по идее, оно и должно быть в большей части случаев.
> Текстовый конфиг хорош тем, что он, как ни тавтологично это звучит, > текстовый. Это значит, что с конфигом можно поступать как с тестом. В > нем можно grep'ать, его можно diff'ать, его можно положить в source > management system, его легко генерить с помощью, скажем, перла.
Однако, если у конфига достаточно сложная структура, то grep уже может
давать сбои. Например,
"A very long \
\line"
При поиске "long line" простым grep'ом уже ничего не получится. А еще
надо учитывать, что иногда в файлах конфигов используются различные
варианты экранирования служебных символов, так что "long line" может
выглядеть как "long\ line" и т.п.
Опять же, для работы с реестром УЖЕ написаны тулзы для diff'а, поиска и
т.п. Да, они дублируют функциональность утилит файловой системы, но они
уже написаны.
> Что касается файловой системы и конфигов, то хранение отдельных > конфигов в отдельных файлах, это, натурально, blessing. Пусть нам надо > передвинуть приложение "брамбрулятор(tm)" с тазика на тазик. В > большинстве случаев надо просто скопировать конфиг > /etc/brambulator.conf и все.
Ну а в реестре он будет в HKLM/Software/Brambulator. Те же яйца, вид сбоку.
> Обеспечить идентичность файлов /etc/brаmbrulator.conf на двух машинах > куда проще, чем (*OMFG*) ветвей реестра.
Идентичность ветвей реестра делается элементарно — экспортируем ветки на
одной машине, и импортируем на другой.
> Дальше. Есть такое слово "ремонтопригодность". Слышали когда-нибудь? > Важное свойство, между прочим. Вкратце, "ремонтопригодный" значит > "если сломалось, можно залезть внутрь и починить", а > "неремонтопригодный" означает "если сломалось, то пиши пропало, неси > на помойку, чтобы не загромождать жизненное пространство". Так вот, > конфиг, который я не могу починить vi'ем (а то и ed'ом), > ремонтопригодным не считается и для реальной жизни не пригоден.
А вот тут надо различать два типа поломок: синтаксические и
семантические. Синтаксические — это если неправильно закрыли тэг и
конфиг стал невалидным. Семантические — это уже глюки с неправильной
комбинацией настроек.
Синтаксических ошибок с реестром не произойдет, так как мы работаем с
ним исключительно через API. Ну а семантические ошибки можно прекрасно
исправлять из regedit'а, даже при полностью упавшей системе.
> Я все понимаю. Красивый API, строгая "инкапсуляция", "ортогональность" > и "абстракции" — это все очень хорошо. Но с чего взяли, что нас, ваших > пользователей, это е^Hволнует? Нет у нас такой задачи про "инкасуляцию > конфигурации".
Прошу заметить: про инкапсюляцию говорил вовсе не я.
> Все эти реестры, gconf'ы и прочая дребедень, совершенно непригодная к > эксплуатации, — это продукт программистского отрыва от реальности.
Как сказать, за годы администрирования систем проблемы с реестром у меня
возникли (дай Бог памяти) один раз — когда я случайно стер скриптом все
ветки в HKLM. А вот с конфигами проблемы постоянные — то симлинки на
include'ы после очередного апдейта сломаются, то формат поменяется на
несовместимый....
Здравствуйте, Cyberax, Вы писали:
C>Как всегда, пришли сисадмины и все испортили
Работа у нас такая.
>> Обеспечить идентичность файлов /etc/brаmbrulator.conf на двух машинах >> куда проще, чем (*OMFG*) ветвей реестра.
C>Идентичность ветвей реестра делается элементарно — экспортируем ветки на C>одной машине, и импортируем на другой.
"Каждая проблема имеет простое, очевидное и неправильное решение".
Так не пойдет. Дело в том, что импорт в реестр не учитывает удаленных и переименованных веток и ключей. Придется удалять всю ветку приложения и только потом импортировать. Отсюда сразу растут проблемы с атомарностью таких манипуляций — надо удостовериться, что приложение не полезет в реестр в процессе всей этой оперции; проблемы с целостностью — удалить удалили, а с импортом косяк вышел: памяти не хватило, места на диске и т.д. Конечно, это все решаемо, но оно мне надо?
C>Синтаксических ошибок с реестром не произойдет, так как мы работаем с C>ним исключительно через API. Ну а семантические ошибки можно прекрасно C>исправлять из regedit'а, даже при полностью упавшей системе.
Как и любой файл сложной структуры реестр может покорраптиться. Неправильный shutdown, сбойная память, сбойный контроллер диска, софтверная ошибка и все, кранты, — вместо реестра кровавое месиво. И ничего, кроме восстановления из бэкапа, не сделать. Текст хоть что-то можно попытаться починить.
C>А вот с конфигами проблемы постоянные — то симлинки на C>include'ы после очередного апдейта сломаются, то формат поменяется на C>несовместимый....
У меня с конфигами конечно проблемы бывали, но чтобы постоянные...
Может, Вы их как-то не так готовите?
Здравствуйте, А почему вы спрашиваете, Вы писали:
C>>А вот с конфигами проблемы постоянные — то симлинки на C>>include'ы после очередного апдейта сломаются, то формат поменяется на C>>несовместимый....
АПВ>У меня с конфигами конечно проблемы бывали, но чтобы постоянные... АПВ>Может, Вы их как-то не так готовите?
А не скажешь, какие конфиги были наиболее удачными, на твой взгляд? С чем удобнее всего было работать?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
А почему вы спрашиваете wrote:
> C>Идентичность ветвей реестра делается элементарно — экспортируем > ветки на > C>одной машине, и импортируем на другой. > "Каждая проблема имеет простое, очевидное и неправильное решение".
Например, конфиг-файлы
> Так не пойдет. Дело в том, что импорт в реестр не учитывает удаленных > и переименованных веток и ключей. Придется удалять всю ветку > приложения и только потом импортировать. Отсюда сразу растут проблемы > с атомарностью таких манипуляций — надо удостовериться, что приложение > не полезет в реестр в процессе всей этой оперции; проблемы с > целостностью — удалить удалили, а с импортом косяк вышел: памяти не > хватило, места на диске и т.д. Конечно, это все решаемо, но оно мне надо?
Ну так с конфиг-файлами ну абсолютно такие же проблемы. Например,
если конфиг состоит из нескольких файлов...
> C>Синтаксических ошибок с реестром не произойдет, так как мы работаем с > C>ним исключительно через API. Ну а семантические ошибки можно прекрасно > C>исправлять из regedit'а, даже при полностью упавшей системе. > Как и любой файл сложной структуры реестр может покорраптиться. > Неправильный shutdown, сбойная память, сбойный контроллер диска, > софтверная ошибка и все, кранты, — вместо реестра кровавое месиво.
А если из-за аппаратных проблем упадет сложная файловая система типа
Reiser4?
> И ничего, кроме восстановления из бэкапа, не сделать. Текст хоть > что-то можно попытаться починить.
При упавшей FS — далеко не факт. Кстати, вот как раз для реестра можно
предусмотреть автоматическое дублирование и использование кодов
коррекции ошибок.
> C>А вот с конфигами проблемы постоянные — то симлинки на > C>include'ы после очередного апдейта сломаются, то формат поменяется на > C>несовместимый.... > У меня с конфигами конечно проблемы бывали, но чтобы постоянные...
Ну не то, чтобы "постоянные", но их было достаточно.
Здравствуйте, Cyberax, Вы писали:
C>А если из-за аппаратных проблем упадет сложная файловая система типа C>Reiser4?
Если она как-то починится, можно руками поправить файлы. У меня такое было — упала ext2 (маленький был, глупый). После ремонта больше всего почему-то пострадал конфиг XFree86. Ничего, починил.
Хотя, конечно, это все равно не решение — нужно делать бекапы.
C>При упавшей FS — далеко не факт. Кстати, вот как раз для реестра можно C>предусмотреть автоматическое дублирование и использование кодов C>коррекции ошибок.
А для FS вообще ничего предусматривать не надо. Регулярный бэкап (tar cj /etc) и/или RAID 1. Можно еще что-нибудь по вкусу. Зачем изобретать велосипеды?
WFrag wrote:
> C>А если из-за аппаратных проблем упадет сложная файловая система типа > C>Reiser4? > Если она как-то починится, можно руками поправить файлы.
А если не починится?
> У меня такое было — упала ext2 (маленький был, глупый). После ремонта > больше всего почему-то пострадал конфиг XFree86. Ничего, починил.
Ну так с реестром так же.
> Хотя, конечно, это все равно не решение — нужно делать бекапы.
Здравствуйте, Cyberax, Вы писали:
C>WFrag wrote:
>> C>А если из-за аппаратных проблем упадет сложная файловая система типа >> C>Reiser4? >> Если она как-то починится, можно руками поправить файлы. C>А если не починится?
А если руги и голова ростут от туда от куда надо тогда у тебя как у нормального
админа ( согласись реанимировать оси дело не програмера а именно админа) будет
стоять РАИД, будут бэкапы, и много чего еще интересного.
>> У меня такое было — упала ext2 (маленький был, глупый). После ремонта >> больше всего почему-то пострадал конфиг XFree86. Ничего, починил. C>Ну так с реестром так же.
А на сколько мне извество излюбленный способ починить Вынь — переустановить её
>> Хотя, конечно, это все равно не решение — нужно делать бекапы. C>Именно
А вот под этим подпишусть полностью...
И всетаки, тщь был прав imho вы програмист а мы любди сопровождающие ваши програмные продукты
или не ваши, за сим думаю что здесь более весомой должна быть точка зрения именно админа...
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, Cyberax, Вы писали:
C>Ну так с конфиг-файлами ну абсолютно такие же проблемы. Например, C>если конфиг состоит из нескольких файлов...
Чаще нет, чем да. В большинстве случаев конфиг — это один файл, rename(2) — атомарная операция. А вот с реестром такая беда всегда, а не в отдельных случаях.
C>А если из-за аппаратных проблем упадет сложная файловая система типа C>Reiser4?
А если пожар в серверной, то вообще ужас. Для потери конфига нужно, чтобы испортилась файловая система. Для потери реестра (в котором лежат конфиги всего) нужно, чтоб испортилась файловая система ИЛИ структура файла, содержащего реестр.
У нас с Вами занятная беседа получается. Вы мне доказываете, путем последовательных улучшений и усовершенствований реестр по удобству асимптотически приближается снизу к файлам-конфигам. Зачем? Зачем оно надо, когда файлы-конфиги уже есть?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>АПВС,
LCR>Может быть не в тему вопрос: как у тебя отношения с Емаксом? На "ты"? На "вы"? На "ты, козёл"? :-D
Здравствуйте, eao197, Вы писали:
E>А не скажешь, какие конфиги были наиболее удачными, на твой взгляд? С чем удобнее всего было работать?
Нет, пожалуй, особенно удачных не назову. Если в ноге нет занозы, то как-то о ней не думаешь.
А вот неудачных примеров есть несколько. Bind — тут явно попутаны конфигурация и application's data: декларации зон не должны быть в named.conf, лечится include'ами. Sendmail — притча во языцех, но m4 делает жизнь проще. Конфигурация солярисного RBAC — полное сумасшествие, несколько ссылающихся друг на друга файлов, каждый из которых определяет неясно что. Не конфиг, но пример очень неудачного синтаксиса: линуксовый iptables — первый приз за кривой синтаксис среди пакетных фильтров.
Я вообще, мне цискин конфиг и cli нравятся, несмотря на некоторые моменты, за которые их можно критиковать. Но это, наверное, потому, что я с этим много работаю.
Возьмем например следующую структуру (JavaScript):
var conf = { one:1, two:2, three:[4,5,6] };
(map из трех элементов, последний массив)
Это будут наши настройки.
При выходе из программы сделаем такое:
var s = Stream.openFile("conf.js","w+");
s.printf( "return %v;" );
s.close();
При этом на диске образуется файл conf.js со следющим содержимиым:
return { one:1, two:2, three:[4,5,6] };
Теперь на старте достаточно сказать:
var conf = exec("conf.js")
|| { one:1, two:2, three:[4,5,6] };
И получим систему сохранения/загрузки настроек.
Достоинства:
a) human-readable configuration,
b) произвольная и гибкая структура (мапы/объекты, массивы и остальные типы данных JS) — вплоть до функций и классов.
с) не требуется отдельный механизм парсинга.
Здравствуйте, c-smile, Вы писали:
CS>Достоинства: CS>a) human-readable configuration, CS>b) произвольная и гибкая структура (мапы/объекты, массивы и остальные типы данных JS) — вплоть до функций и классов. CS>с) не требуется отдельный механизм парсинга.
CS>Самому понравилось.
Здравствуйте, А почему вы спрашиваете, Вы писали:
АПВ>Текстовый конфиг хорош тем, что он, как ни тавтологично это звучит, текстовый. Это значит, что с конфигом можно поступать как с тестом. В нем можно grep'ать, его можно diff'ать, его можно положить в source management system, его легко генерить с помощью, скажем, перла. Сама по себе текстовость дает конфигу массу полезных свойств. Автоматически, просто в силу его текстовости, так сказать, в подарок, и без дополнительных усилий со стороны вендора.
Это определяется только теми инструментами, которые у тебя есть.
АПВ>Что касается файловой системы и конфигов, то хранение отдельных конфигов в отдельных файлах, это, натурально, blessing.
согласен
АПВ>Дальше. Есть такое слово "ремонтопригодность". Слышали когда-нибудь? Важное свойство, между прочим. Вкратце, "ремонтопригодный" значит "если сломалось, можно залезть внутрь и починить", а "неремонтопригодный" означает "если сломалось, то пиши пропало, неси на помойку, чтобы не загромождать жизненное пространство". Так вот, конфиг, который я не могу починить vi'ем (а то и ed'ом), ремонтопригодным не считается и для реальной жизни не пригоден.
Ремонт поврежденных данных — это вообще отдельная песня и к собственно структуре конфигов отношенияи не имеет. Для этого есть журналирующие файловые системы, бэкап и т.п.
АПВ>Все эти реестры, gconf'ы и прочая дребедень, совершенно непригодная к эксплуатации, — это продукт программистского отрыва от реальности.
Это просто продукт больного воображения и кривых рук. Не надо распространять результаты на идею в целом
Здравствуйте, Дарней, Вы писали:
Д>Это определяется только теми инструментами, которые у тебя есть.
Безусловно. И для текстовых файлов этих инструментов больше. О том и речь.
АПВ>>Что касается файловой системы и конфигов, то хранение отдельных конфигов в отдельных файлах, это, натурально, blessing.
Д>Ремонт поврежденных данных — это вообще отдельная песня и к собственно структуре конфигов отношенияи не имеет. Для этого есть журналирующие файловые системы, бэкап и т.п.
Журналируемые файловые системы защищают только от определенных видов сбоев. Ни от сбоев памяти, ни от сбоев контроллеров дисков, ни от софтверных ошибок они не защищают.
Наличие бэкапа даже не обсуждается — бэкап должен быть и точка. Однако бэкап — это как запасной парашют, он должен быть, он должен быть исправен, но прыгать с одной только запаской нельзя.
Фундаментальное свойство бэкапа в том, что он всегда отстает во времени от актуального сосотояния. И это значит, что данные таки приходится иногда ремонтировать, а не тупо восстанавливать. Текст ремонтировать легче.
АПВ>>Все эти реестры, gconf'ы и прочая дребедень, совершенно непригодная к эксплуатации, — это продукт программистского отрыва от реальности.
Д>Это просто продукт больного воображения и кривых рук. Не надо распространять результаты на идею в целом
На какую идею? На идею бинарного конфига? Это плохая идея. У нее нет эксплуатационных преимуществ, но у нее есть заметные эксплуатационные недостатки.
Здравствуйте, А почему вы спрашиваете, Вы писали:
АПВ>Безусловно. И для текстовых файлов этих инструментов больше. О том и речь.
их больше — потому что сейчас везде используются именно они (если говорить про мир юниксов).
Зачем нужно придумывать новые языки? Ведь для них нет никаких инструментов и на них никто не пишет
АПВ>Журналируемые файловые системы защищают только от определенных видов сбоев. Ни от сбоев памяти, ни от сбоев контроллеров дисков, ни от софтверных ошибок они не защищают.
А что, текстовая структура способна защитить от кривых рук программиста, который вместо обновления значения параметра стер его вообще? Ну ничего себе
Что касается сбоев памяти и аппаратных сбоев... если уж железо действительно посыплется, то фиг ты чего восстановишь из блока памяти, забитого нулями, к примеру. Будь твой конфиг хоть десять раз текстовый.
Зато бинарный формат с контрольными значениями и резервированием данных имеет все шансы восстановиться автоматически.
АПВ>Фундаментальное свойство бэкапа в том, что он всегда отстает во времени от актуального сосотояния. И это значит, что данные таки приходится иногда ремонтировать, а не тупо восстанавливать. Текст ремонтировать легче.
вручную — да. Хотя по хорошему это должно делаться автоматически, если это так уж критично для системы.
Д>>Это просто продукт больного воображения и кривых рук. Не надо распространять результаты на идею в целом
АПВ>На какую идею? На идею бинарного конфига? Это плохая идея. У нее нет эксплуатационных преимуществ, но у нее есть заметные эксплуатационные недостатки.
Нет эксплуатационных преимуществ? Как насчет select * from parameters where value="foo" ? Только не рассказывай мне про grep — чтобы его использовать, нужно помнить внутреннюю структуру конфига (sic!), нужно думать про обработку специальных символов (всевозможные \\ и &) и разбиение длинных значений по строкам.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
