Outside the Unix world, this three-orders-of-magnitude improvement in
C>hardware performance has been masked to a significant extent by a
C>corresponding drop in software performance.
C>
Another part of the fault must be laid to the failure of OO itself to
C>live up to expectations. We examined this problem in Chapter 4
C>(Modularity), observing the tendency of OO methods to lead to thick glue
C>layers and maintenance problems. Today, inspection of open-source
C>archives (in which choice of language reflects developers' judgements
C>rather than corporate mandates) reveals that C++ usage is still heavily
C>concentrated in GUIs and multimedia toolkits and games (the major
C>success areas for OO design) and little used elsewhere.
C>
IDEs make a lot of sense for single-language programming in a
C>tool-poor environment. If what you're doing is confined to grinding out
C>C or C++ code by hand and the yard, they're quite appropriate. Under
C>Unix, however, your languages and implementation options are a lot more
C>varied. It's common to use multiple code generators, custom
C>configurators, and many other standard and custom tools.
C>См. топик "XEmacs — помойка" в Unix'овом разделе насчет моих мнений об этом.
Можно эти части оспорить, конечно. Но ничего особо смешного я здесь не вижу.
Что касается производительности, то он очень близок к истине. Взять хотя бы виндовый реестр — самая неудачная идея из всех возможных неудачных идей. Как с точки зрения архитектуры (нарушение инкапсуляции данных), так и с точки зрения производительности.
Здравствуйте, Дарней, Вы писали:
Д>Можно эти части оспорить, конечно. Но ничего особо смешного я здесь не вижу. Д>Что касается производительности, то он очень близок к истине. Взять хотя бы виндовый реестр — самая неудачная идея из всех возможных неудачных идей. Как с точки зрения архитектуры (нарушение инкапсуляции данных), так и с точки зрения производительности.
Знаешь, громандные текстовики со всем подряд в ранних версиях юнихов еще хуже.
Здравствуйте, AndrewVK, Вы писали:
Д>>Можно эти части оспорить, конечно. Но ничего особо смешного я здесь не вижу. Д>>Что касается производительности, то он очень близок к истине. Взять хотя бы виндовый реестр — самая неудачная идея из всех возможных неудачных идей. Как с точки зрения архитектуры (нарушение инкапсуляции данных), так и с точки зрения производительности.
AVK>Знаешь, громандные текстовики со всем подряд в ранних версиях юнихов еще хуже.
Идеальный вариант, ИМХО — это единый формат бинарного хранения данных с отдельным хранилищем для каждого приложения и пользователя. ASN.1 например. А еще лучше — база данных.
Только юниксоиды упорно держатся за текстовые форматы... в том числе и за этот сверх-тормозной XML
AVK>>Знаешь, громандные текстовики со всем подряд в ранних версиях юнихов еще хуже. X>Ага, как вспомню фалйы конфигураций T-Mail, Bink, Squish, GoldEd — так вздрогну
Пф. Они вообще интуитивно-понятны. Вот конфиг сендмейла — это да. Вызывает уважение.
Дарней wrote: > AVK>Знаешь, громандные текстовики со всем подряд в ранних версиях юнихов > еще хуже. > > Идеальный вариант, ИМХО — это единый формат бинарного хранения данных с > отдельным хранилищем для каждого приложения и пользователя. ASN.1 > например. А еще лучше — база данных. > Только юниксоиды упорно держатся за текстовые форматы... в том числе и > за этот сверх-тормозной XML.
Хочется насильственного разделения настроек пользователей/приложений
между собой. Сейчас его программа может нарушить, но больше умышленно.
Plain Text можно править всегда, если есть доступ к файловой системе на
чтение. Смена формата на бинарный — наложение новых требований. С
sed+head+tail+cat+echo уже не так будет легко править (сейчас, впрочем,
тоже весело). Бинарным можно сделать кеш настроек, но это делать надо —
никому это настолько, похоже, не нужно.
Дарней wrote:
> Можно эти части оспорить, конечно. Но ничего особо смешного я здесь не > вижу. > Что касается производительности, то он очень близок к истине. Взять > хотя бы виндовый реестр — самая неудачная идея из всех возможных > неудачных идей.
Да, по неудачности она идет как раз после юниксовых файлов конфигурации.
> Как с точки зрения архитектуры (нарушение инкапсуляции данных), так и > с точки зрения производительности.
Ээээ... А где у вас инкапсюляция данных, например, в apache.conf?
Ну а на производительность вообще гнать не надо, реестр — это маленькая
БД, даже с индексацией. И работает оно обычно даже быстрее текстовых
файлов с конфигами.
Cyberax wrote: >> Можно эти части оспорить, конечно. Но ничего особо смешного я здесь не >> вижу. >> Что касается производительности, то он очень близок к истине. Взять >> хотя бы виндовый реестр — самая неудачная идея из всех возможных >> неудачных идей. > > Да, по неудачности она идет как раз после юниксовых файлов конфигурации.
Не сказал бы, что после.. > >> Как с точки зрения архитектуры (нарушение инкапсуляции данных), так и >> с точки зрения производительности. > > Ээээ... А где у вас инкапсюляция данных, например, в apache.conf?
Во-первых, в том, что в файле не лежат настройки монитора. Во-вторых
include во многих программах с большими настройками позволяет разделить
группы по файлам. > Ну а на производительность вообще гнать не надо, реестр — это маленькая > БД, даже с индексацией. И работает оно обычно даже быстрее текстовых > файлов с конфигами.
Про производительность верю. Скорее вопрос в том, что его засорить легче.
Здравствуйте, raskin, Вы писали:
R>Во-первых, в том, что в файле не лежат настройки монитора.
Тогда сама файловая система есть нарушение инкапсуляции.
Ветки в реестре не более и не менее отдельны чем файлы в файловой системе. Реести и есть файловая истема (только у него нет общаего для ОС интерфейса ФС)
В принципе, надо раобраться почему сделан реестр насколько я помню идея была в том, чтобы сделать единый быстрый кешированный механизм хранения настроек.
mibe wrote: > Ветки в реестре не более и не менее отдельны чем файлы в файловой > системе. Реести и есть файловая истема (только у него нет общаего для ОС > интерфейса ФС)
Угу. Только злобный вирус жрёт его как один/десять файлов. И timestamp
получить трудно (мне лично). И diff -r для него не написан. Из-за таких
пустяков он и не всегда удобен.
raskin wrote:
> Угу. Только злобный вирус жрёт его как один/десять файлов.
Ничерта вирус файлам реестра не сделает — они заблокированы
пользователем system.
> И timestamp получить трудно (мне лично).
Ну никто не говорил, что реестр — идеален. Но вот для первой реализации
— вполне ничего.
> И diff -r для него не написан. Из-за таких пустяков он и не всегда удобен.
diff для реестра давно написан. У меня называется regdiff.exe —
сравнивает между собой reg-файлы и ветки рееста.
raskin wrote:
>> Ээээ... А где у вас инкапсюляция данных, например, в apache.conf? > Во-первых, в том, что в файле не лежат настройки монитора.
А /etc/X11/XF86Config — это галлюцинация?
А вообще, для управления устройствами рулит WMI. Только MS как обычно
его не доделал нормально.
> Во-вторых include во многих программах с большими настройками > позволяет разделить > группы по файлам.
Ну так делите по веткам в чем проблемы? Реестр же иерархический.
Здравствуйте, mibe, Вы писали:
M>В принципе, надо раобраться почему сделан реестр насколько я помню идея была в том, чтобы сделать единый быстрый кешированный механизм хранения настроек.
ReiserFS4 отвечает предъявленным требованиям, зачем городить огород на пустом месте непонятно. У МС кроме реестра есть еще минимум одна "файловая система" — та которая storage через com
Cyberax wrote: >> Угу. Только злобный вирус жрёт его как один/десять файлов. > > Ничерта вирус файлам реестра не сделает — они заблокированы > пользователем system.
И то радует. А появился он, кстати, в NT или в 95? В 9х он был (и есть)
в этом смысле неудачен.
>> И timestamp получить трудно (мне лично). > > Ну никто не говорил, что реестр — идеален. Но вот для первой реализации > — вполне ничего.
Но только зачем?
>> И diff -r для него не написан. Из-за таких пустяков он и не всегда удобен. > > diff для реестра давно написан. У меня называется regdiff.exe — > сравнивает между собой reg-файлы и ветки рееста.
Это буду знать. Но сравнивает он не копии dat-файлов, а всё-таки
reg-файлс реестром. Так я могу и 2 reg-файла сравнить (так я делал).
Кроме того, отсутствие интерфейса ФС не даёт читать реестр
проводником+блокнотом, а требует пользоваться конкретным GUI или его
аналогами (с похожим видом). Хотя уже существуют текстовые. Деланье
boot-дискет реестр усложняет (возможно, теперь это менее актуально). Он
лишняя сущность, от которой много зависит и которую нельзя игнорировать.
Cyberax wrote: > raskin wrote: > >> > Ээээ... А где у вас инкапсюляция данных, например, в apache.conf? >> Во-первых, в том, что в файле не лежат настройки монитора. > > А /etc/X11/XF86Config — это галлюцинация?
Я имел в виду apache.conf . Кстати да, галлюцинация для 1/2 Linux-оидов. > > А вообще, для управления устройствами рулит WMI. Только MS как обычно > его не доделал нормально.
Вот Unix-оиды не хотят повторять славный путь.
Управление устройствами, кстати, очень стоит хранить текстом — ссоры
устройств можно было бы разруливать из-под консоли, предварительно их
деинициализировав (а... опять перезагрузка.. за что?). И не думать про
Safe Mode без своего на то желания.
> >> Во-вторых include во многих программах с большими настройками >> позволяет разделить >> группы по файлам. > > Ну так делите по веткам в чем проблемы? Реестр же иерархический.
Нет, это-то реестр позволяет. Только в apache.conf пользователь
(извините, администратор) решает, что он вынесет, а что оставит в файле.
Lazy Cjow Rhrr wrote:
> C> [реестр — молодец?] > Есть у реестра ещё один недостаток. Если я открываю файл smb.conf, то > у меня к каждому пункту подробный комментарий. Если я открываю реестр —
smb.conf бывают разные — в том числе и без комментариев. Кстати, я
где-то видел редактор реестра, который для каждого ключа показывал
документацию из MSDN. Хотя идея сделать еще и универсальный формат для
хелпов с привязкой к ключам реестра — совсем неплохая.
> Ждём второй версии MS Ultimate Registry.
А вот фиг. Это же MS — от них нормального вечно не дождешься.
raskin wrote:
>> Ничерта вирус файлам реестра не сделает — они заблокированы >> пользователем system. > И то радует. А появился он, кстати, в NT или в 95? В 9х он был (и есть) > в этом смысле неудачен.
Еще в Win3.0 для поддержки OLE.
>> Ну никто не говорил, что реестр — идеален. Но вот для первой реализации >> — вполне ничего. > Но только зачем?
Унифицировать формат файлов с конфигами.
>> diff для реестра давно написан. У меня называется regdiff.exe — >> сравнивает между собой reg-файлы и ветки рееста. > Это буду знать. Но сравнивает он не копии dat-файлов, а всё-таки > reg-файлс реестром. Так я могу и 2 reg-файла сравнить (так я делал).
А какая разница? Вы же не сравниваете файлы с помощью прямого чтения
диска, вы пользуетесь API для работы с FS.
Хотя утилиты для сравнения физических файлов реестра тоже есть — их
обычно используют при восстановлении системы после сбоев.
> Кроме того, отсутствие интерфейса ФС не даёт читать реестр > проводником+блокнотом, а требует пользоваться конкретным GUI или его > аналогами (с похожим видом).
У меня используется плугин к FAR'у, который позволяет ходить по реестру
(в том числе и удаленному или в виде reg-файла) как по обычному диску.
> Хотя уже существуют текстовые. Деланье boot-дискет реестр усложняет > (возможно, теперь это менее актуально). Он > лишняя сущность, от которой много зависит и которую нельзя игнорировать.
Ну так конфиг-файлы — тоже усложняют создание boot-дискет. Они тогда
тоже — лишняя сущность?
Quintanar wrote:
> M>В принципе, надо раобраться почему сделан реестр насколько я помню > идея была в том, чтобы сделать единый быстрый кешированный механизм > хранения настроек. > ReiserFS4 отвечает предъявленным требованиям, зачем городить огород на > пустом месте непонятно. У МС кроме реестра есть еще минимум одна > "файловая система" — та которая storage через com
Не отвечает. Оверхед будет в десятки раз больше, даже для такой
оптимизированной системы как reiser4. Кроме того, в начале 90х годов ее
еще в природе не было, а если бы и была — то ресурсов тогдашних
компьютеров не хватило бы для ее поддержки.
Здравствуйте, Cyberax, Вы писали:
C>Ээээ... А где у вас инкапсюляция данных, например, в apache.conf?
вероятно, в слове "apache" в названии файла
C>Ну а на производительность вообще гнать не надо, реестр — это маленькая C>БД, даже с индексацией. И работает оно обычно даже быстрее текстовых C>файлов с конфигами.
Быстрее текстового конфига с таким же объемом данных — это я конечно не спорю. Но текстовых конфигов такого объема просто не бывает — никто еще не додумался сделать один текстовый конфиг на всю систему, к счастью
Здравствуйте, mibe, Вы писали:
M>Ветки в реестре не более и не менее отдельны чем файлы в файловой системе. Реести и есть файловая истема (только у него нет общаего для ОС интерфейса ФС)
в реестре нельзя настроить права доступа на ветки по юзерам/группам
Дарней,
> M>Ветки в реестре не более и не менее отдельны чем файлы в файловой системе. Реести и есть файловая истема (только у него нет общаего для ОС интерфейса ФС)
> в реестре нельзя настроить права доступа на ветки по юзерам/группам
Тьфу! думал про одно, написал про другое
главная проблема с реестром (как и с файловой системой) — то, что нельзя настроить права доступа отдельно для каждого приложения
Здравствуйте, Дарней, Вы писали:
Д>Тьфу! думал про одно, написал про другое Д>главная проблема с реестром (как и с файловой системой) — то, что нельзя настроить права доступа отдельно для каждого приложения
А что считать "приложением"? Как отделить одно приложение от другого?
Дарней wrote:
> C>Ээээ... А где у вас инкапсюляция данных, например, в apache.conf? > вероятно, в слове "apache" в названии файла
Ну вот, а в реестре будет в названии ветки HKLM/Software/Apache.
> C>Ну а на производительность вообще гнать не надо, реестр — это маленькая > C>БД, даже с индексацией. И работает оно обычно даже быстрее текстовых > C>файлов с конфигами. > Быстрее текстового конфига с таким же объемом данных — это я конечно > не спорю. Но текстовых конфигов такого объема просто не бывает — никто > еще не додумался сделать один текстовый конфиг на всю систему, к счастью
Оно за счет индексирования и кэширования скорее всего будет быстрее и
маленького текстового файла. А если еще учитывать, что не нужно тратить
время на парсинг конфигов.
Здравствуйте, Cyberax, Вы писали:
C>Точно так же, как и для файлов конфигов.
не совсем точно так же. К примеру, описания компонентов для всех приложений валятся в одну кучу. Чем некоторые программисты пользуются для того, чтобы скрывать там информацию — о сроке работы пробной версии, например.
C>И решение точно такое же — C>запускать приложения из под специальных пользователей.
это да... но под каждое приложение создавать отдельного пользователя — не очень веселое занятие
Здравствуйте, Cyberax, Вы писали:
C>Ну вот, а в реестре будет в названии ветки HKLM/Software/Apache.
И в названии ветки HKCR тоже?
C>Оно за счет индексирования и кэширования скорее всего будет быстрее и C>маленького текстового файла. А если еще учитывать, что не нужно тратить C>время на парсинг конфигов.
Реестр — он не бывает маленький. А большой реестр не будет быстрее маленького текстового файла — это однозначно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[11]: Э.Реймонд "Искусство программирования для Unix"
Здравствуйте, Дарней, Вы писали:
Д>Тьфу! думал про одно, написал про другое Д>главная проблема с реестром (как и с файловой системой) — то, что нельзя настроить права доступа отдельно для каждого приложения
Заведи для приложения отдельную учетную запись и нет проблем.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Э.Реймонд "Искусство программирования для Unix"
Здравствуйте, Cyberax, Вы писали:
C>Дарней wrote:
C>Ну а на производительность вообще гнать не надо, реестр — это маленькая C>БД, даже с индексацией. И работает оно обычно даже быстрее текстовых C>файлов с конфигами.
А править текстовый конфиг гораздо удобней, особенно если нужно это делать ручками
как было уже сказано, текстовых конфигов такого объема просто не бывает ( у меня
реестр после экспорта занял 31,479,352 ).
И если Вам необходимо подправить
пару десятков параметров в текстовике вы сделаете это гораздо быстрее чем будете
прагыть во веткам реестра кликать мышькой и т.п.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Э.Реймонд "Искусство программирования для Unix"
Дарней wrote:
> VD>Заведи для приложения отдельную учетную запись и нет проблем. > учетная запись для ворда, учетная запись для пейнта... не многовато > будет?
Ну в юниксах так и делают. В моем /etc/passwd есть: qmaild, qmails,
qmailr, qmailq, qmailp, mysql, nobody, identd, irc, gnats, ejabberd,
Debian-exim, majordomo и еще штук пять.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[13]: Э.Реймонд "Искусство программирования для Unix"
Здравствуйте, Дарней, Вы писали:
Д>учетная запись для ворда, учетная запись для пейнта... не многовато будет?
А зачем тебе для ворда то отдельную учетную запись заводить? Я так понимаю, что речь идет о каком-то особенном случае. Вот для него и заводить. Например, из какого-нить Аутлука прет зараза. Чтобы чего не вышло завести учетную запись с огранивенными правами, дать ей доступ куда нужно и запускать Аутлук через нее.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Э.Реймонд "Искусство программирования для Unix"
Здравствуйте, VladD2, Вы писали:
VD>А зачем тебе для ворда то отдельную учетную запись заводить? Я так понимаю, что речь идет о каком-то особенном случае. Вот для него и заводить. Например, из какого-нить Аутлука прет зараза. Чтобы чего не вышло завести учетную запись с огранивенными правами, дать ей доступ куда нужно и запускать Аутлук через нее.
Я имел в виду ситуацию в общем... такая "общедоступность" данных — это просто неправильно, ИМХО
а решать проблему через фиктивные пользовательские записи — это просто костыли
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[9]: Э.Реймонд "Искусство программирования для Unix"
raskin wrote:
>>> > Ээээ... А где у вас инкапсюляция данных, например, в apache.conf? >>> Во-первых, в том, что в файле не лежат настройки монитора. >> А /etc/X11/XF86Config — это галлюцинация? > Я имел в виду apache.conf .
Врете. У меня настройки монитора в дефолтном конфиге Дебиана лежат в
каталоге /etc/apache/../X11! Где же здесь инкапсюляция?
> Кстати да, галлюцинация для 1/2 Linux-оидов.
Кстати, не меньшая проблема — отсутствие стандартных методов поиска
конфигов.
> Вот Unix-оиды не хотят повторять славный путь. > Управление устройствами, кстати, очень стоит хранить текстом — ссоры > устройств можно было бы разруливать из-под консоли, предварительно их > деинициализировав (а... опять перезагрузка.. за что?).
У меня конфликт устройств в последний раз был в 99 году (еще на
материнке с ISA-слотами). Ну а в чем проблема один раз зайти в hardware
monitor и поправить параметры — не представляю.
>> Ну так делите по веткам в чем проблемы? Реестр же иерархический. > Нет, это-то реестр позволяет. Только в apache.conf пользователь > (извините, администратор) решает, что он вынесет, а что оставит в файле.
И что? Пусть в хороших прогах конфиги делятся на HKLM-ные и HKCU-шные.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[15]: Э.Реймонд "Искусство программирования для Unix"
Дарней wrote:
> VD>А зачем тебе для ворда то отдельную учетную запись заводить? Я так > понимаю, что речь идет о каком-то особенном случае. Вот для него и > заводить. Например, из какого-нить Аутлука прет зараза. Чтобы чего не > вышло завести учетную запись с огранивенными правами, дать ей доступ > куда нужно и запускать Аутлук через нее. > Я имел в виду ситуацию в общем... такая "общедоступность" данных — это > просто неправильно, ИМХО > а решать проблему через фиктивные пользовательские записи — это просто > костыли
Ну так файлы конфигов тоже, в общем-то, общедоступны (с учетом прав,
естественно). Так что тут вопрос уже доверия к приложению.
punk4 wrote:
> C>Ну а на производительность вообще гнать не надо, реестр — это маленькая > C>БД, даже с индексацией. И работает оно обычно даже быстрее текстовых > C>файлов с конфигами. > А править текстовый конфиг гораздо удобней, особенно если нужно это > делать ручками > как было уже сказано
Ну так сделайте программу, которая будет интерпретировать реестр как
текстовый файл. Кстати, реестр можно править в виде .reg-файлов, которые
абсолютно текстовые.
> И если Вам необходимо подправить пару десятков параметров в текстовике > вы сделаете это гораздо быстрее чем будете > прагыть во веткам реестра кликать мышькой и т.п.
У меня реестр достпен как виртуальный каталог в FAR'е, так что все
спокойно делается без мышки. А вообще, работа с реестром не должна быть
обычным делом — нужны специальные графические оболочки для нужных
настроек. Например, "Control Panel".
Здравствуйте, Cyberax, Вы писали:
C>А вообще, работа с реестром не должна быть C>обычным делом — нужны специальные графические оболочки для нужных C>настроек. Например, "Control Panel".
А если хочется сделать нечто не задуманное изначально в утилите настройки?
Собственно, предлагаю прочитать (если не читал) правило разделения (Rule of Separation: Separate policy from mechanism; separate interfaces from engines) в книге "The Art of Unix Programming". И сказать, в чем ты с ней не согласен.
Утилиты обработки текстов общего назначения (find, grep, sed, etc) заведомо покрывают большую функциональность, чем ты можешь покрыть в своей оболчке для настройки чего-либо.
Зачем отбирать возможность использовать эту мощь? Хочется высокого уровня и простоты — используй утилиты настройки, фронтенды. Но зачем их ставить во главу угла?
Например, я запросто могу положить свой /etc в CVS. Реестр — нет. Или пустить поиск по сложному критерию. Или найти разницу между двумя версиями конфига. И для этого мне не нужны специальные утилиты.
Здравствуйте, Cyberax, Вы писали:
C>Ну так сделайте программу, которая будет интерпретировать реестр как C>текстовый файл. Кстати, реестр можно править в виде .reg-файлов, которые C>абсолютно текстовые.
Да уж, абсолютно, вот вам значение произвольно из первого попавшегося места
{23170F69-40C1-278A-1000-000100020000}
расскажите ка мне что он оно значит?????
C>У меня реестр достпен как виртуальный каталог в FAR'е, так что все C>спокойно делается без мышки. А вообще, работа с реестром не должна быть C>обычным делом — нужны специальные графические оболочки для нужных C>настроек. Например, "Control Panel".
А у меня конфигурационные файлы доступны в vi, vim, joe, emacs и что вам
еще будет угодно, при желании хоть в Worde можно править с использованием
всей мощи которую предлагает то или иное средство. IMHO панимание приходит
быстрее и лучше когда руками и головой делаешь а не галки ставишь в окнах.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Э.Реймонд "Искусство программирования для Unix"
Здравствуйте, Cyberax, Вы писали:
C>Ну так файлы конфигов тоже, в общем-то, общедоступны (с учетом прав, C>естественно). Так что тут вопрос уже доверия к приложению.
На самом деле проблема даже не в злонамеренных прогах. Нередко бывает так, что прога портит чужую ветку просто по причине криворукости автора (см также про нецелевое использование веток)
Залезть в чужой файл конфига по ошибке — это существенно сложнее даже для самого криворукого программера
WFrag wrote:
> C>А вообще, работа с реестром не должна быть > C>обычным делом — нужны специальные графические оболочки для нужных > C>настроек. Например, "Control Panel". > А если хочется сделать нечто не задуманное изначально в утилите настройки?
Тогда welcome to regedit, или welcome to WMI в WindowsXP.
> Собственно, предлагаю прочитать (если не читал) правило разделения > (Rule of Separation: Separate policy from mechanism; separate > interfaces from engines) в книге "The Art of Unix Programming". И > сказать, в чем ты с ней не согласен.
Оно хорошо подходит для программирования, но не для пользовательского
интерфейса.
> Утилиты обработки текстов общего назначения (find, grep, sed, etc) > заведомо покрывают большую функциональность, чем ты можешь покрыть в > своей оболчке для настройки чего-либо.
Блин, мне не нужно покрывать большую функциональность, мне даже не нужно
покрывать всю функциональность. Мне лишь нужно сделать 99% самых часто
используемых функций легкодоступными из GUI. Для остального — есть
скриптовой интерфейс.
Так что ли сложно понять?
> Зачем отбирать возможность использовать эту мощь? Хочется высокого > уровня и простоты — используй утилиты настройки, фронтенды. Но зачем > их ставить во главу угла?
А затем, что они УДОБНЫ для использования.
> Например, я запросто могу положить свой /etc в CVS. Реестр — нет.
А tdsam базу из Samba? Или там базы mysql'а?
> Или пустить поиск по сложному критерию.
Можно.
> Или найти разницу между двумя версиями конфига.
regdiff.exe
> И для этого мне не нужны специальные утилиты.
punk4 wrote:
> C>Ну так сделайте программу, которая будет интерпретировать реестр как > C>текстовый файл. Кстати, реестр можно править в виде .reg-файлов, > которые > C>абсолютно текстовые. > Да уж, абсолютно, вот вам значение произвольно из первого попавшегося > места > {23170F69-40C1-278A-1000-000100020000} > расскажите ка мне что он оно значит?????
Расскажите, что значит "szap -n 1 -x"?
Уже запустили man? Так вот, я уже запустил MSDN.
> C>У меня реестр достпен как виртуальный каталог в FAR'е, так что все > C>спокойно делается без мышки. А вообще, работа с реестром не должна быть > C>обычным делом — нужны специальные графические оболочки для нужных > C>настроек. Например, "Control Panel". > А у меня конфигурационные файлы доступны в vi, vim, joe, emacs и что вам > еще будет угодно
Но вот, к сожалению, не доступны из центрального удобного пользователю
средства конфигурирования. Всякие webmin'ы пока еще не очень развиты.
> при желании хоть в Worde можно править с использованием > всей мощи которую предлагает то или иное средство. IMHO панимание приходит > быстрее и лучше когда руками и головой делаешь а не галки ставишь в окнах.
Здравствуйте, Cyberax, Вы писали:
C>Оно хорошо подходит для программирования, но не для пользовательского C>интерфейса.
Почему? Идея проста — не навязывай жестких ограничений. plain-text конфигурация содержит минимум оных. Хочешь высокоуровневый интерфейс — пожайлуста, пиши фронтенд! Хочешь низкоуровневый текстовый — пожайлуста, используй готовые сто-лет-назад-написанные тектовые утилиты!
А, например, при скриптовом подходе тебе уже навязываются ограничения. В виде онтологии (понятий и их связи) конфигурационного файла. Ты уже не можешь трактовать данные просто как текст (например, чтобы сделать тот же diff), ты вынужден трактовать их как осмысленные данные со строгой структурой.
C>Блин, мне не нужно покрывать большую функциональность, мне даже не нужно C>покрывать всю функциональность.
О чем и речь — тебе не нужно. Мне — нужно. Не всегда, но как запасной вариант чтобы был.
C>Мне лишь нужно сделать 99% самых часто C>используемых функций легкодоступными из GUI. Для остального — есть C>скриптовой интерфейс.
C>Так что ли сложно понять?
Скриптовый интерфейс — это не то. Он все равно задает ограничения. Пример — текстовый diff. Работает с любым тектовым файлом (конечно, при соблюдении этим файлом неких разумных ограничений на структуру).
C>А затем, что они УДОБНЫ для использования.
Ну так и сделай их именно фронтендами к текстовым конфигам.
C>А tdsam базу из Samba? Или там базы mysql'а?
ХЗ что это. Я про настройки говорю, кои в /etc.
C>Можно.
Ну, скажем, найти и заменить по регекспу. Опять отдельная утилита? Почему бы просто не воспользоваться уже готовым, скажем sed?
C>Что такое "специальные утилиты"?
WFrag wrote:
> C>Оно хорошо подходит для программирования, но не для пользовательского > C>интерфейса. > Почему? Идея проста — не навязывай жестких ограничений. plain-text > конфигурация содержит минимум оных. Хочешь высокоуровневый интерфейс — > пожайлуста, пиши фронтенд! Хочешь низкоуровневый текстовый — > пожайлуста, используй готовые сто-лет-назад-написанные тектовые утилиты!
Ну так для реестра тоже давно уже нужные утилиты написаны, и
высокоуровневый интерфейс делать значительно удобнее, так как API для
доступа к реестру уже давно есть.
> А, например, при скриптовом подходе тебе уже навязываются ограничения. > В виде онтологии (понятий и их связи) конфигурационного файла. Ты уже > не можешь трактовать данные просто как текст (например, чтобы сделать > тот же diff), ты вынужден трактовать их как осмысленные данные со > строгой структурой.
Я могу сделать из реестра .reg-файл со всеми вытекающими последствиями.
> C>Блин, мне не нужно покрывать большую функциональность, мне даже не > нужно > C>покрывать всю функциональность. > О чем и речь — тебе не нужно. Мне — нужно. Не всегда, но как запасной > вариант чтобы был.
Так он есть — реестр прекрасно доступен для утилит. А для работы с
устройствами вообще есть специальный скриптовой интерфейс WMI.
> C>А затем, что они УДОБНЫ для использования. > Ну так и сделай их именно фронтендами к текстовым конфигам.
Сложно, нужно писать прямые и обратные парсеры для текстовых файлов. И
большинство разработчиков просто этим пренебрегают.
> C>А tdsam базу из Samba? Или там базы mysql'а? > ХЗ что это. Я про настройки говорю, кои в /etc.
Ну так там далеко не все есть.
> C>Можно. > Ну, скажем, найти и заменить по регекспу. Опять отдельная утилита? > Почему бы просто не воспользоваться уже готовым, скажем sed?
Экспортируем нужный ключ в .reg и дальше sed'ом. Потом имортируем
обратно в реестр, причем все это можно сделать через пайпы в лучшем
стиле Юникса.
А еще можно использовать WMI:
Set colItems = objWMIService.ExecQuery("Select * from
Win32_ComputerSystem",,48)
For Each objItem in colItems
objTextFile.WriteLine("Manufacturer: " & objItem.Manufacturer)
objTextFile.WriteLine("Model: " & objItem.Model)
objTextFile.WriteLine("Name: " & objItem.Name)
objTextFile.WriteLine("NumberOfProcessors: " & objItem.NumberOfProcessors)
objTextFile.WriteLine("TotalPhysicalMemory: " & objItem.TotalPhysicalMemory)
objTextFile.WriteLine("UserName: " & objItem.UserName)
Next
> C>Что такое "специальные утилиты"? > regdiff.exe
Cyberax wrote: > Еще в Win3.0 для поддержки OLE.
Но его погром, кажется, не был так опасен. >> > Ну никто не говорил, что реестр — идеален. Но вот для первой реализации >> > — вполне ничего. >> Но только зачем? > Унифицировать формат файлов с конфигами.
Прыжок — попытка улететь. А если нужны чуть сложнее что делать?
>> > diff для реестра давно написан. У меня называется regdiff.exe — >> > сравнивает между собой reg-файлы и ветки рееста. >> Это буду знать. Но сравнивает он не копии dat-файлов, а всё-таки >> reg-файлс реестром. Так я могу и 2 reg-файла сравнить (так я делал). > > А какая разница? Вы же не сравниваете файлы с помощью прямого чтения > диска, вы пользуетесь API для работы с FS. > > Хотя утилиты для сравнения физических файлов реестра тоже есть — их > обычно используют при восстановлении системы после сбоев.
Да, это я ерунду сказал про то, что с чем.
>> Кроме того, отсутствие интерфейса ФС не даёт читать реестр >> проводником+блокнотом, а требует пользоваться конкретным GUI или его >> аналогами (с похожим видом). > > У меня используется плугин к FAR'у, который позволяет ходить по реестру > (в том числе и удаленному или в виде reg-файла) как по обычному диску.
Ну, это существует, но Вы же сами говорили "а если ничего не
прикручивать, а чтоб работало..". Мне удобно не вылезать из ViM. И по
файлам ходить им (да, урезано. Но иногда достаточно + привычка, что copy
в командной строке набирать не проблема). И я не уверен, есть ли решение
для ViM.
>> Хотя уже существуют текстовые. Деланье boot-дискет реестр усложняет >> (возможно, теперь это менее актуально). Он >> лишняя сущность, от которой много зависит и которую нельзя игнорировать. > > Ну так конфиг-файлы — тоже усложняют создание boot-дискет. Они тогда > тоже — лишняя сущность?
Что надо на Rescue (не привязывая к системе)? Интерпретатор команд,
драйвера для чтения с разных устройств — возражений нет. Наверное,
что-то для работы с текстом. Редактор, вроде как. Небольшой. Критичные
куски настроек. Без перечисленного обойтись — можно, но не хочется. Под
любой ОС. И тут — что-то для реестра. Содержащее фактически драйвер и
дублирующее редактор. Либо имеющее расходы на сопряжение с редактором.
Если бы была идея "храните настройке на спец. разделе (можно loopback),
и это обычная ФС" — было бы легче.
Posted via RSDN NNTP Server 2.0 beta
Re[14]: Э.Реймонд "Искусство программирования для Unix"
Cyberax wrote: > Ну в юниксах так и делают. В моем /etc/passwd есть: qmaild, qmails, > qmailr, qmailq, qmailp, mysql, nobody, identd, irc, gnats, ejabberd, > Debian-exim, majordomo и еще штук пять.
Это не то, это для демонов — и, как правильно сказал Влад, чтобы если
что — зараза не полезла. А вот в LFS на полном серьёзе рекомендуется
система управления приложениями, когда *все* (а не только постоянно
меняемые/настроечные) файлы *любого* (не только сетевого) приложения
имеют свой UID. В том числе UID libc и libstdc++ разный.
Posted via RSDN NNTP Server 2.0 beta
Re[16]: Э.Реймонд "Искусство программирования для Unix"
raskin wrote:
>> Ну так файлы конфигов тоже, в общем-то, общедоступны (с учетом прав, >> естественно). Так что тут вопрос уже доверия к приложению. > Ну, тут, по слухам (не пробовал) ввели SELinux, который позволяет ТАКОЕ > начудить. > А проверенный метод — запускать под chroot. Но это, увы, требует прав > root.
Кстати, в Винде есть runas (и программные API для имперсонации), который
работает под любым пользователем — нужно только знать credential'ы
пользователя, под которым приложение запускается.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[15]: Э.Реймонд "Искусство программирования для Unix"
raskin wrote:
>> Ну в юниксах так и делают. В моем /etc/passwd есть: qmaild, qmails, >> qmailr, qmailq, qmailp, mysql, nobody, identd, irc, gnats, ejabberd, >> Debian-exim, majordomo и еще штук пять. > Это не то, это для демонов — и, как правильно сказал Влад, чтобы если > что — зараза не полезла.
А что демоны — это не приложения? Хотя смотря какие демоны
> А вот в LFS на полном серьёзе рекомендуется система управления > приложениями, когда *все* (а не только постоянно > меняемые/настроечные) файлы *любого* (не только сетевого) приложения > имеют свой UID. В том числе UID libc и libstdc++ разный.
Идея, кстати, неплохая. Правда тогда поддержка ACLей получается весьма
интересной.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[16]: Э.Реймонд "Искусство программирования для Unix"
Cyberax wrote: > raskin wrote: >> > Ну в юниксах так и делают. В моем /etc/passwd есть: qmaild, qmails, >> > qmailr, qmailq, qmailp, mysql, nobody, identd, irc, gnats, ejabberd, >> > Debian-exim, majordomo и еще штук пять. >> Это не то, это для демонов — и, как правильно сказал Влад, чтобы если >> что — зараза не полезла. > > А что демоны — это не приложения? Хотя смотря какие демоны
Там была идея учётки для paint. > >> А вот в LFS на полном серьёзе рекомендуется система управления >> приложениями, когда *все* (а не только постоянно >> меняемые/настроечные) файлы *любого* (не только сетевого) приложения >> имеют свой UID. В том числе UID libc и libstdc++ разный. > > Идея, кстати, неплохая. Правда тогда поддержка ACLей получается весьма > интересной.
Легко — кому нужен apache — в группу. Я не говорил, что идея плоха —
просто как дальнейшее развитие. Идея .. красивая в смысле hack.
Posted via RSDN NNTP Server 2.0 beta
Re[18]: Э.Реймонд "Искусство программирования для Unix"
Cyberax wrote: >> > Ну так файлы конфигов тоже, в общем-то, общедоступны (с учетом прав, >> > естественно). Так что тут вопрос уже доверия к приложению. >> Ну, тут, по слухам (не пробовал) ввели SELinux, который позволяет ТАКОЕ >> начудить. >> А проверенный метод — запускать под chroot. Но это, увы, требует прав >> root. > > Кстати, в Винде есть runas (и программные API для имперсонации), который > работает под любым пользователем — нужно только знать credential'ы > пользователя, под которым приложение запускается.
su -c . Про API не скажу сразу, но и без API самому написать замену API
недолго.
Posted via RSDN NNTP Server 2.0 beta
Re[10]: Э.Реймонд "Искусство программирования для Unix"
Cyberax wrote: >> >> > Ээээ... А где у вас инкапсюляция данных, например, в apache.conf? >> >> Во-первых, в том, что в файле не лежат настройки монитора. >> > А /etc/X11/XF86Config — это галлюцинация? >> Я имел в виду apache.conf . > > Врете. У меня настройки монитора в дефолтном конфиге Дебиана лежат в > каталоге /etc/apache/../X11! Где же здесь инкапсюляция?
Дебиан крут. Если это умолчание. Но это из серии "сделайте Ваш выбор".
>> Кстати да, галлюцинация для 1/2 Linux-оидов. > > Кстати, не меньшая проблема — отсутствие стандартных методов поиска > конфигов. >
Документация по программе.. locate conf... Логи (искать по timestamp?).
Дистрибутив, документирующий правила складывания настроек. А так,
конечно, бардак. Но документация часто выручает.
Но поиск по реестру (при небольшой фантазии в названии корневой ветки)
тоже не скучен. >> Вот Unix-оиды не хотят повторять славный путь. >> Управление устройствами, кстати, очень стоит хранить текстом — ссоры >> устройств можно было бы разруливать из-под консоли, предварительно их >> деинициализировав (а... опять перезагрузка.. за что?). > У меня конфликт устройств в последний раз был в 99 году (еще на > материнке с ISA-слотами). Ну а в чем проблема один раз зайти в hardware > monitor и поправить параметры — не представляю
А сейчас перезагрузка после этого нужна?
>> > Ну так делите по веткам в чем проблемы? Реестр же иерархический. >> Нет, это-то реестр позволяет. Только в apache.conf пользователь >> (извините, администратор) решает, что он вынесет, а что оставит в файле. > > И что? Пусть в хороших прогах конфиги делятся на HKLM-ные и HKCU-шные.
Не понял. Я имею в виду вынос независимой части файла, чтоб читать не
мешала. Чтоб было как fold в ViM. Но без привязки к средствам. Программа
может, разумеется, обрабатывать переменную структуры своей ветки реестра
(сильно переменную), но это не принято.
Posted via RSDN NNTP Server 2.0 beta
Re[17]: Э.Реймонд "Искусство программирования для Unix"
raskin wrote:
>>> А вот в LFS на полном серьёзе рекомендуется система управления >>> приложениями, когда *все* (а не только постоянно >>> меняемые/настроечные) файлы *любого* (не только сетевого) приложения >>> имеют свой UID. В том числе UID libc и libstdc++ разный. >> Идея, кстати, неплохая. Правда тогда поддержка ACLей получается весьма >> интересной. > Легко — кому нужен apache — в группу.
Неудобно, группы в Винде и Линуксе представлены в виде плоского списка,
и если создавать на каждый Апач по группе, то в этом списке становится
трудно ориентироваться.
> Я не говорил, что идея плоха — просто как дальнейшее развитие. Идея .. > красивая в смысле hack.
Угу.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[19]: Э.Реймонд "Искусство программирования для Unix"
raskin wrote:
>> Кстати, в Винде есть runas (и программные API для имперсонации), который >> работает под любым пользователем — нужно только знать credential'ы >> пользователя, под которым приложение запускается. > su -c . Про API не скажу сразу, но и без API самому написать замену API > недолго.
runas в отличие от su после первого логина credential'ы еще умеет и
запоминать. Хотя это при желании и в Линуксе можно сделать.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[17]: Э.Реймонд "Искусство программирования для Unix"
Quintanar wrote:
> C>Идея, кстати, неплохая. Правда тогда поддержка ACLей получается весьма > C>интересной. > Опять же в Reiser4 ACL очень органично сделаны. К ним можно обращаться > как к файлам.
Однако даже в Reiser'е поиск всех файлов с данной entry в ACL занимает
линейное время (и может быть достаточно долгое), так что операции по
установке/удалению приложений будут медленными.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[18]: Э.Реймонд "Искусство программирования для Unix"
Cyberax wrote: >> >> А вот в LFS на полном серьёзе рекомендуется система управления >> >> приложениями, когда *все* (а не только постоянно >> >> меняемые/настроечные) файлы *любого* (не только сетевого) приложения >> >> имеют свой UID. В том числе UID libc и libstdc++ разный. >> > Идея, кстати, неплохая. Правда тогда поддержка ACLей получается весьма >> > интересной. >> Легко — кому нужен apache — в группу. > > Неудобно, группы в Винде и Линуксе представлены в виде плоского списка, > и если создавать на каждый Апач по группе, то в этом списке становится > трудно ориентироваться.
Ну, тогда FS менять, согласен. Хотя зачем весь список когда бы то ни
было читать целиком и глазами — не понял. Добавить пользователя в
группу/добавить группу. Но это дело вкуса.
Posted via RSDN NNTP Server 2.0 beta
Re[20]: Э.Реймонд "Искусство программирования для Unix"
Cyberax wrote: >> > Кстати, в Винде есть runas (и программные API для имперсонации), который >> > работает под любым пользователем — нужно только знать credential'ы >> > пользователя, под которым приложение запускается. >> su -c . Про API не скажу сразу, но и без API самому написать замену API >> недолго. > > runas в отличие от su после первого логина credential'ы еще умеет и > запоминать. Хотя это при желании и в Линуксе можно сделать.
Права root и 1 час — и всё будет наверняка (Это — кратная
перестраховка). В freebsd sudo запоминает — это я знаю.
Здравствуйте, Cyberax, Вы писали:
C>Врете. У меня настройки монитора в дефолтном конфиге Дебиана лежат в C>каталоге /etc/apache/../X11! Где же здесь инкапсюляция?
Что-то я не понял логики.
Что с твоей точки зрения "инкапсуляция" (в данной ситуации)?
Здравствуйте, Cyberax, Вы писали:
C>Но вот, к сожалению, не доступны из центрального удобного пользователю C>средства конфигурирования. Всякие webmin'ы пока еще не очень развиты.
Так вот и развивайте, ведь вам нужны удабные средства, а мне вообще-то
хватает текстовиков.
И вообще кто сказал что-то про пользователя? Пользователю ИМХО незачем знать
токной настройки системы иначе и я и вы и еще куча людей останемся без работы,
а для того чтобы "Ура! Склад!" ему хватает и webmin.
C>Да ничерта оно не приходит быстрее.
Не соглашусь, но испорить не буду у всех поразному.
mibe wrote:
> C>А какая разница? Вы же не сравниваете файлы с помощью прямого чтения > C>диска, вы пользуетесь API для работы с FS. > тут у меня скорее претензия, что это API не такое же как для работы с > ФС. то есть что реестр концептуально похож на ФС, но не является ФС.
API для реестра все же должно отличаться от файловой системы, так как
ключи — это не файлы.
raskin wrote:
>> Еще в Win3.0 для поддержки OLE. > Но его погром, кажется, не был так опасен.
Там тогда не хранились жизненно важные настройки — они были в ini-файлах И вот как раз ими очень легко было все порушить.
>>> Но только зачем? >> Унифицировать формат файлов с конфигами. > Прыжок — попытка улететь. А если нужны чуть сложнее что делать?
Если ТОЧНО нельзя уложиться в унифицированый формат — то делать свое. Но
почти все известные мне конфиги в него укладываются нормально.
>> У меня используется плугин к FAR'у, который позволяет ходить по реестру >> (в том числе и удаленному или в виде reg-файла) как по обычному диску. > Ну, это существует, но Вы же сами говорили "а если ничего не > прикручивать, а чтоб работало..".
Так редактирование реестра должно быть не обычной операцией для пользователя. Ну а админ уже будет знать про FAR/TC/....
> Мне удобно не вылезать из ViM. И по файлам ходить им (да, урезано. Но > иногда достаточно + привычка, что copy > в командной строке набирать не проблема). И я не уверен, есть ли > решение для ViM.
Напишите
>> Ну так конфиг-файлы — тоже усложняют создание boot-дискет. Они тогда >> тоже — лишняя сущность? > Что надо на Rescue (не привязывая к системе)? Интерпретатор команд, > драйвера для чтения с разных устройств — возражений нет. Наверное, > что-то для работы с текстом. Редактор, вроде как. Небольшой. Критичные > куски настроек. Без перечисленного обойтись — можно, но не хочется. Под > любой ОС. И тут — что-то для реестра. Содержащее фактически драйвер и > дублирующее редактор.
Имея все настройки в реестре можно обойтись и без текстового редактора
(см. recovery console в Win2k/xp).
punk4 wrote:
> C>Но вот, к сожалению, не доступны из центрального удобного пользователю > C>средства конфигурирования. Всякие webmin'ы пока еще не очень развиты. > Так вот и развивайте, ведь вам нужны удабные средства, а мне вообще-то > хватает текстовиков.
Так именно текстовые конфиги и мешают развитию нормальных средств.
Например, webmin у меня несколько раз портил конфиги (путал комментарии,
неправильно форматировал) — с реестром таких проблем бы не было.
> И вообще кто сказал что-то про пользователя? Пользователю ИМХО незачем > знать > токной настройки системы иначе и я и вы и еще куча людей останемся без > работы
Простите, моя работа — это не ходить и настраивать Linux'ы. Моя работы —
писать программы, так что без работы я не останусь.
Cyberax wrote: >> > Еще в Win3.0 для поддержки OLE. >> Но его погром, кажется, не был так опасен. > > Там тогда не хранились жизненно важные настройки — они были в ini-файлах > И вот как раз ими очень легко было все порушить.
Я знаю.
Но там были 2-3 файла, которые надо читать+копировать до того, как
править (win.ini,system.ini — всё?), а остальные громили пару программ.
И опять же их было легко править из DOS. И программа обычно гробила свой
конфиг. А системный всё равно архивировать полезно.
>> >> Но только зачем? >> > Унифицировать формат файлов с конфигами. >> Прыжок — попытка улететь. А если нужны чуть сложнее что делать? > > Если ТОЧНО нельзя уложиться в унифицированый формат — то делать свое. Но > почти все известные мне конфиги в него укладываются нормально.
>> > У меня используется плугин к FAR'у, который позволяет ходить по реестру >> > (в том числе и удаленному или в виде reg-файла) как по обычному диску. >> Ну, это существует, но Вы же сами говорили "а если ничего не >> прикручивать, а чтоб работало..". > > Так редактирование реестра должно быть не обычной операцией для > *пользователя*. Ну а админ уже будет знать про FAR/TC/.... > >> Мне удобно не вылезать из ViM. И по файлам ходить им (да, урезано. Но >> иногда достаточно + привычка, что copy >> в командной строке набирать не проблема). И я не уверен, есть ли >> решение для ViM. > > Напишите
К счастью, я сейчас не завязан на реестр. Правлю изредка — автозапуск
там отключаю. Большое время провожу в Linux. Поэтому писать лень.
>> > Ну так конфиг-файлы — тоже усложняют создание boot-дискет. Они тогда >> > тоже — лишняя сущность? >> Что надо на Rescue (не привязывая к системе)? Интерпретатор команд, >> драйвера для чтения с разных устройств — возражений нет. Наверное, >> что-то для работы с текстом. Редактор, вроде как. Небольшой. Критичные >> куски настроек. Без перечисленного обойтись — можно, но не хочется. Под >> любой ОС. И тут — что-то для реестра. Содержащее фактически драйвер и >> дублирующее редактор. > > Имея все настройки в реестре можно обойтись и без текстового редактора > (см. recovery console в Win2k/xp).
Не понял? А boot.ini куда? Его туда можно? А если я не знаю, много ли
(или не я) грохнул — может, до fdisk дойдёт — recovery console требует
же >> дискеты — если я не ошибаюсь, CD нормального размера (или на
маленький/флешку 128М тоже влезет?). А если я документацию захочу
почитать в процессе — мне её на дискетку сподручнее кидать txt (или
архивом, если архиватор окупится). Сейчас, наверное, действительно лучше
BootCD, там, конечно проблема места менее актуальна — но лишнюю сущность
городить зачем-то.
Cyberax wrote: > Так именно текстовые конфиги и мешают развитию нормальных средств. > Например, webmin у меня несколько раз портил конфиги (путал комментарии, > неправильно форматировал) — с реестром таких проблем бы не было.
Не понял, Вы хотите сказать, что не бывает TweakTool после которой в
реестре мусор вместо настроек?
Posted via RSDN NNTP Server 2.0 beta
Re[11]: Э.Реймонд "Искусство программирования для Unix"
WFrag wrote:
> C>Врете. У меня настройки монитора в дефолтном конфиге Дебиана лежат в > C>каталоге /etc/apache/../X11! Где же здесь инкапсюляция? > Что-то я не понял логики. > Что с твоей точки зрения "инкапсуляция" (в данной ситуации)?
Мне это самому интересно было — откуда берется инкапсюляция в файловой
системе?
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[12]: Э.Реймонд "Искусство программирования для Unix"
Здравствуйте, Cyberax, Вы писали:
C>punk4 wrote:
C>Так именно текстовые конфиги и мешают развитию нормальных средств. C>Например, webmin у меня несколько раз портил конфиги (путал комментарии, C>неправильно форматировал) — с реестром таких проблем бы не было.
Ну вот и подошли, раз писать так писать! Напишите что-то что будет лучше
WEBMIN`а а потом и говорите что он плох.
C>Простите, моя работа — это не ходить и настраивать Linux'ы. Моя работы — C>писать программы, так что без работы я не останусь.
А это смотря как к вопросу подойти, не исключено что выучив тонкости настройки
реестра выни пользователи перестанут выполнять свое естественное
предназначение и только и будут заниматься тем что выправлять ветки после
того как воспользуются одной из ваших утилит для настроки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Э.Реймонд "Искусство программирования для Unix"
WFrag wrote:
> C>Мне это самому интересно было — откуда берется инкапсюляция в файловой > C>системе? > Еще раз повторю вопрос, я спросил что с твоей точки зрения > инкапсуляция в данной ситуации.
Инкапсюляция будет, если каждое приложение станет хранить свои данные в
закрытых от других приложений "черном ящике". А в файловой системе
инкапсюляции нет.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[14]: Э.Реймонд "Искусство программирования для Unix"
Здравствуйте, Cyberax, Вы писали:
C>Инкапсюляция будет, если каждое приложение станет хранить свои данные в C>закрытых от других приложений "черном ящике". А в файловой системе C>инкапсюляции нет.
Чем тебе закрытый для чтения другими каталог — не черный ящик?
Возникает вопрос, как определять "identity" того, кто доступается к данным. Пусть для простоты это будет пользователь, от имени которого запущен проуесс.
Здравствуйте, Cyberax, Вы писали:
>> C>А какая разница? Вы же не сравниваете файлы с помощью прямого чтения >> C>диска, вы пользуетесь API для работы с FS. >> тут у меня скорее претензия, что это API не такое же как для работы с >> ФС. то есть что реестр концептуально похож на ФС, но не является ФС.
C>API для реестра все же должно отличаться от файловой системы, так как C>ключи — это не файлы.
приведи определение понятия файл, из которого бы это следовало
Кстати, удобство использование файлменеджера для управления реестром это подтверждает.
WFrag wrote:
> C>Инкапсюляция будет, если каждое приложение станет хранить свои данные в > C>закрытых от других приложений "черном ящике". А в файловой системе > C>инкапсюляции нет. > Чем тебе закрытый для чтения другими каталог — не черный ящик?
Нет, так как при достаточных правах другая программа может его прочесть.
> Возникает вопрос, как определять "identity" того, кто доступается к > данным. Пусть для простоты это будет пользователь, от имени которого > запущен проуесс.
Ну это просто — смотрим PID процесса, пытающегося получить доступ к
файлу, а дальше все просто.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[16]: Э.Реймонд "Искусство программирования для Unix"
Здравствуйте, Cyberax, Вы писали:
C>WFrag wrote:
>> C>Инкапсюляция будет, если каждое приложение станет хранить свои данные в >> C>закрытых от других приложений "черном ящике". А в файловой системе >> C>инкапсюляции нет. >> Чем тебе закрытый для чтения другими каталог — не черный ящик?
C>Нет, так как при достаточных правах другая программа может его прочесть.
Назови хоть одну причину зачем нужна такая параноидальная защита? И почему чужой программе нельзя читать этот файл? Так и так его надо редактировать, искать по нему, бэкапить. Отсюда следует, что к файлу должны иметь доступ несколько программ, и проблему с доступом легко решить в рамках файловой системы, не создавая еще одно ее подобие.
Re[16]: Э.Реймонд "Искусство программирования для Unix"
Здравствуйте, Cyberax, Вы писали:
C>Нет, так как при достаточных правах другая программа может его прочесть.
При достаточных правах можно вообще все прочитать. В Java, например, тоже можно сломать инкапсуляцию — прочитать чужое приватное поле. И что?
C>Ну это просто — смотрим PID процесса, пытающегося получить доступ к C>файлу, а дальше все просто.
И что? Прав-то у тебя все-равно не будет. Если процесс запущен от имени пользователя pupkin и только этому пользователю позволено читать/писать /etc/pupkin то хоть засмотримь на PID, тебе это ничего не даст.
Конечно, такая реализация "identity" приложения довольно примитивна, но это уже другой вопрос. Например, в Java эта самая идентичность может определяться по подписи, расположению класса, и.т.д.
И вообще, я так и не понял, что ты понимаешь под инкапсуляцией. Определение в студию, пожайлуста. Я вообще считаю, что к инкапсуляции это имеет малое отношение. То, что другое приложение может свободно прочитать чужие настройки, на мой взгляд, никак инкапсуляцию не нарушает.
А нарушает ее настройки монитора в конфиге Самбы (например).
Здравствуйте, mibe, Вы писали:
M>тут у меня скорее претензия, что это API не такое же как для работы с ФС. то есть что реестр концептуально похож на ФС, но не является ФС.
Ключевое слово — похож.
Реестр хранит типизированные значения вроде строки и DWORD. Файл же хранит только бинарные денные (даже текстовый) интерпретация которых ведет некое приложение. Другими словами реестр — это скорее БД нежели ФС. Общее у них только иерархичность.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
mibe wrote:
> C>API для реестра все же должно отличаться от файловой системы, так как > C>ключи — это не файлы. > приведи определение понятия файл, из которого бы это следовало
Файл — нетипизированый набор байт, а ключ реестра имеет тип (DWORD,
ASCIIZ, ...)
> Кстати, удобство использование файлменеджера для управления реестром > это подтверждает.
Файлменеджер вообще удобен для навигации по любой иерархической
структуре. Я вот его использую даже для редактирования xml
VladD2 wrote: > Реестр хранит типизированные значения вроде строки и DWORD. Файл же > хранит только бинарные денные (даже текстовый) интерпретация которых > ведет некое приложение. Другими словами реестр — это скорее БД нежели > ФС. Общее у них только иерархичность.
Это трактовка данных. Всё равно, в DWORD запихивается 4 символа — при
желании. И CPUID этим пользуется. А у файлов бывают расширения. И ФС,
позволяющая ограничить размер файла — не вопрос. Про извращения *nix на
тему "это тоже файл" достаточно упомянуть. Кстати, со специальными
файлами можно сделать не всё, но и то, что можно, облегчает жизнь.
Здравствуйте, 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!), нужно думать про обработку специальных символов (всевозможные \\ и &) и разбиение длинных значений по строкам.
Здравствуйте, Дарней, Вы писали:
АПВ>>На какую идею? На идею бинарного конфига? Это плохая идея. У нее нет эксплуатационных преимуществ, но у нее есть заметные эксплуатационные недостатки.
Д>Нет эксплуатационных преимуществ? Как насчет select * from parameters where value="foo" ? Только не рассказывай мне про grep — чтобы его использовать, нужно помнить внутреннюю структуру конфига (sic!), нужно думать про обработку специальных символов (всевозможные \\ и &) и разбиение длинных значений по строкам.
Круто, однако
Как двоичный формат, с SQL-подобными запросами, так value может содержать только "foo". А как текстовый конфиг, так там не только escaping, но еще и разбиение длинных значений по строкам. Да и когда мы SQL-подобный запрос в двоичном конфиге делаем нам, конечно, логическую стуктуру знать не нужно -- ведь там только value и все, никаких тебе user.bob.auth.password или group.admins.rights и в помине нет. Какие-то двойные стандарты получаются
Хотя использовать grep с XML -- это действительно тяжеловато, имхо. А вот C-подобный escaping, как правило, проблем не вызывает, поскольку префиксуется, обычно всего несколько символов (обратная косая, кавычки, иногда \n и \t). Зато в grep-е офигенные регулярные выражения задавать можно.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Круто, однако E>Как двоичный формат, с SQL-подобными запросами, так value может содержать только "foo". А как текстовый конфиг, так там не только escaping, но еще и разбиение длинных значений по строкам.
Ну это просто пример... лень было набирать Пусть это будет не foo, а например список всех расширений, которые зарегистрированы в конфиге MySQL. Ваши варианты? С помощью регулярных выражений и такой-то матери?
E>Да и когда мы SQL-подобный запрос в двоичном конфиге делаем нам, конечно, логическую стуктуру знать не нужно -- ведь там только value и все, никаких тебе user.bob.auth.password или group.admins.rights и в помине нет. Какие-то двойные стандарты получаются
наверно, я просто неточно сформулировал. Чтобы искать информацию в текстовом файле — нужно знать не только его логическую структуру, но и то, как она представлена в самом файле. Например, нужно знать, как помечаются секции, отдельные параметры внутри секций и т.п. Когда ты работаешь с базой данных, знания о внутреннем представлении данных тебе не нужны.
E>Зато в grep-е офигенные регулярные выражения задавать можно.
К сожалению, на грабли с их помощью тоже очень легко наступать. Не говоря уже об их write-only синтаксисе.
Здравствуйте, Дарней, Вы писали:
E>>Как двоичный формат, с SQL-подобными запросами, так value может содержать только "foo". А как текстовый конфиг, так там не только escaping, но еще и разбиение длинных значений по строкам.
Д>Ну это просто пример... лень было набирать Пусть это будет не foo, а например список всех расширений, которые зарегистрированы в конфиге MySQL. Ваши варианты? С помощью регулярных выражений и такой-то матери?
Сразу история вспоминается, с которой мне довелось столкнуться. Мои коллеги написали софт, который считывает свою конфигурацию из отдельной таблички в БД. Да там конфигурации всего-то одна строка с пятью или шестью столбцами. А запускалась софтина с параметрами подключения к БД в командной строке. И в один прекрасный день потребовалось один параметр в конфигурации поправить. Никого из разработчиков, как водится, под рукой нет. Только я случайно рядом оказался. И вот что обидно -- есть непосредственный доступ к машине на которой крутится софт и сервер БД. Но нет инструментов для того, чтобы в табличке SQL базы одно значение поправить. Ну то есть нет ни одной приблуды, в которой можно было бы update написать. Да еще машина была не в локалке. Матюгался я тогда изрядно. С тех пор к конфигурации в недоступных vi или far двоичных форматах отношусь крайне негативно. Просто потому, что когда жареный петух клевать начинает, нужных инструментов, как водится, под рукой не оказывается. А текстовый редактор -- он практически везде есть.
E>>Да и когда мы SQL-подобный запрос в двоичном конфиге делаем нам, конечно, логическую стуктуру знать не нужно -- ведь там только value и все, никаких тебе user.bob.auth.password или group.admins.rights и в помине нет. Какие-то двойные стандарты получаются
Д>наверно, я просто неточно сформулировал. Чтобы искать информацию в текстовом файле — нужно знать не только его логическую структуру, но и то, как она представлена в самом файле. Например, нужно знать, как помечаются секции, отдельные параметры внутри секций и т.п. Когда ты работаешь с базой данных, знания о внутреннем представлении данных тебе не нужны.
Т.е. тебе не нужно думать, что выражение "Bob's Blog" в конфиге записывается как Bob\'s Blog или Bob's Blog? Да такое есть.
Но ведь в РСУБД тебе нужно знать названия таблиц, столбцов, а в случае сложных данных -- еще и отношения между ними. Это ведь так же не слабое знание логической структуры.
E>>Зато в grep-е офигенные регулярные выражения задавать можно.
Д>К сожалению, на грабли с их помощью тоже очень легко наступать. Не говоря уже об их write-only синтаксисе.
Зато они хорошо сохраняются в .sh (.bat) файлах, а затем легко повторно используются. С sql-запросами, конечно, такое так же возможно. Но вот как быть с поиском по реестру, например?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Сразу история вспоминается, с которой мне довелось столкнуться. Мои коллеги написали софт, который считывает свою конфигурацию из отдельной таблички в БД. Да там конфигурации всего-то одна строка с пятью или шестью столбцами. А запускалась софтина с параметрами подключения к БД в командной строке. И в один прекрасный день потребовалось один параметр в конфигурации поправить. Никого из разработчиков, как водится, под рукой нет. Только я случайно рядом оказался. И вот что обидно -- есть непосредственный доступ к машине на которой крутится софт и сервер БД. Но нет инструментов для того, чтобы в табличке SQL базы одно значение поправить. Ну то есть нет ни одной приблуды, в которой можно было бы update написать. Да еще машина была не в локалке. Матюгался я тогда изрядно. С тех пор к конфигурации в недоступных vi или far двоичных форматах отношусь крайне негативно. Просто потому, что когда жареный петух клевать начинает, нужных инструментов, как водится, под рукой не оказывается. А текстовый редактор -- он практически везде есть.
Ну это опять же вопрос доступности инструментов. А если стандартизовать единый формат для бинарных конфигов и в каждом дистрибутиве будет удобный редактор/навигатор по нему?
E>Т.е. тебе не нужно думать, что выражение "Bob's Blog" в конфиге записывается как Bob\'s Blog или Bob's Blog? Да такое есть.
Нет, я не совсем это имел в виду. Логическая организация файла — это когда нужно думать, что нужные тебе данные в конфиге могут выглядеть как variable=value, <variable>value</variable>, variable:value, variable!value или как-то еще.
К твоей задаче (найти нужную переменную) это на самом деле не имеет отношения — просто ненужная добавочная нагрузка.
E>Но вот как быть с поиском по реестру, например?
Здравствуйте, eao197, Вы писали:
E>Сразу история вспоминается, с которой мне довелось столкнуться. Мои коллеги написали софт, который считывает свою конфигурацию из отдельной таблички в БД. Да там конфигурации всего-то одна строка с пятью или шестью столбцами. А запускалась софтина с параметрами подключения к БД в командной строке. И в один прекрасный день потребовалось один параметр в конфигурации поправить. Никого из разработчиков, как водится, под рукой нет. Только я случайно рядом оказался. И вот что обидно -- есть непосредственный доступ к машине на которой крутится софт и сервер БД. Но нет инструментов для того, чтобы в табличке SQL базы одно значение поправить. Ну то есть нет ни одной приблуды, в которой можно было бы update написать. Да еще машина была не в локалке. Матюгался я тогда изрядно. С тех пор к конфигурации в недоступных vi или far двоичных форматах отношусь крайне негативно. Просто потому, что когда жареный петух клевать начинает, нужных инструментов, как водится, под рукой не оказывается. А текстовый редактор -- он практически везде есть.
Ну это опять же вопрос доступности инструментов. А если стандартизовать единый формат для бинарных конфигов и в каждом дистрибутиве будет удобный редактор/навигатор по нему?
E>Т.е. тебе не нужно думать, что выражение "Bob's Blog" в конфиге записывается как Bob\'s Blog или Bob's Blog? Да такое есть.
Нет, я не совсем это имел в виду. Логическая организация файла — это когда нужно думать, что нужные тебе данные в конфиге могут выглядеть как variable=value, <variable>value</variable>, variable:value, variable!value или как-то еще.
К твоей задаче (найти нужную переменную) это на самом деле не имеет отношения — просто ненужная добавочная нагрузка.
E>Но вот как быть с поиском по реестру, например?
c-smile wrote:
> Достоинства: > a) human-readable configuration, > b) произвольная и гибкая структура (мапы/объекты, массивы и остальные > типы данных JS) — вплоть до функций и классов. > с) не требуется отдельный механизм парсинга. > Самому понравилось.
d) Можно устраивать конкурсы obfuscated конфигов.
e) Синтаксис, не поддающийся никакому автоматическому разбору.
Здравствуйте, Дарней, Вы писали:
Д>Ну это опять же вопрос доступности инструментов. А если стандартизовать единый формат для бинарных конфигов и в каждом дистрибутиве будет удобный редактор/навигатор по нему?
Единый бинарный формат? Да еще удобный. Да еще с продвинутыми инструментами. Да еще чтобы были везде, начиная от Windows и заканчивая Symbian OS или AIX, или NonStop Kernel.
По каждому из пунктов у меня очень большие сомнения.
E>>Т.е. тебе не нужно думать, что выражение "Bob's Blog" в конфиге записывается как Bob\'s Blog или Bob's Blog? Да такое есть.
Д>Нет, я не совсем это имел в виду. Логическая организация файла — это когда нужно думать, что нужные тебе данные в конфиге могут выглядеть как variable=value, <variable>value</variable>, variable:value, variable!value или как-то еще. Д>К твоей задаче (найти нужную переменную) это на самом деле не имеет отношения — просто ненужная добавочная нагрузка.
А мне кажется, что здесь что-то не так. Если я ищу переменную по имени, то я ищу просто variable. Если я ищу по значению, то ищу просто value.
E>>Но вот как быть с поиском по реестру, например?
Д>Не совсем понял, что ты имеешь в виду.
Ну вот мне вообще интересно, как в реестре сохранять структуры, которые в конфиге легко можно задавать повторяющимися тегами:
вот как нужно в реестре сохранить всех операторов и все message_state_name для каждого из операторов. И как затем найти все message_state_name для конкретного оператора?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Единый бинарный формат? Да еще удобный. Да еще с продвинутыми инструментами. Да еще чтобы были везде, начиная от Windows и заканчивая Symbian OS или AIX, или NonStop Kernel.
E>По каждому из пунктов у меня очень большие сомнения.
Пока таких вариантов и правда не видно. Может быть потому, что в них никто не верит?
E>А мне кажется, что здесь что-то не так. Если я ищу переменную по имени, то я ищу просто variable. Если я ищу по значению, то ищу просто value.
а если это value равно "0", например? получишь в нагрузку целую кучу результатов, из которых надо еще выбрать нужный
E>Ну вот мне вообще интересно, как в реестре сохранять структуры, которые в конфиге легко можно задавать повторяющимися тегами: E>
E>вот как нужно в реестре сохранить всех операторов и все message_state_name для каждого из операторов. И как затем найти все message_state_name для конкретного оператора?
мы ведь вроде бы говорили про базы данных? а виндовый реестр — и правда неудачная реализация, ИМХО. Взять хотя бы это уродство с регистрацией COMпонентов и множеством зависимостей между ветками, например
Здравствуйте, Cyberax, Вы писали:
>> Достоинства: >> a) human-readable configuration, >> b) произвольная и гибкая структура (мапы/объекты, массивы и остальные >> типы данных JS) — вплоть до функций и классов. >> с) не требуется отдельный механизм парсинга. >> Самому понравилось.
C>d) Можно устраивать конкурсы obfuscated конфигов. C>e) Синтаксис, не поддающийся никакому автоматическому разбору.
Собственно, если попробовать развить идею дальше, то можно вполне представить себе C++ приложение, которое собирается Ruby (Python, Tcl/Tk) скриптом в единое целое.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
E>>По каждому из пунктов у меня очень большие сомнения.
Д>Пока таких вариантов и правда не видно. Может быть потому, что в них никто не верит?
А неверит потому, что одна половина сомневается в возможности создания таких инструментов, а вторая половина сомневается в необходимости подобных инструментов
E>>А мне кажется, что здесь что-то не так. Если я ищу переменную по имени, то я ищу просто variable. Если я ищу по значению, то ищу просто value.
Д>а если это value равно "0", например? получишь в нагрузку целую кучу результатов, из которых надо еще выбрать нужный
Элементарно
grep -r "0" *.cfg | grep "reconnect-timeout"
Д>мы ведь вроде бы говорили про базы данных? а виндовый реестр — и правда неудачная реализация, ИМХО. Взять хотя бы это уродство с регистрацией COMпонентов и множеством зависимостей между ветками, например
Ну мы тут не только про базы данных говорили
Но, с другой стороны, это программисту легко sql-ный select слабать, чтобы по нескольким таблицам выборку сделать. А вот имеет ли смысл требовать того же от администратора?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>Ну это опять же вопрос доступности инструментов. А если стандартизовать единый формат для бинарных конфигов и в каждом дистрибутиве будет удобный редактор/навигатор по нему?
Интересно, а какой плюс дает "бинарность" конфига? Что мешает тебе стандартизовать формат текстового конфига и гонять запросы по нему?
Ну, пусть это будет XML. Запросы — XPath, редактирование в GUI делается на основе схемы.
Здравствуйте, WFrag, Вы писали:
WF>Интересно, а какой плюс дает "бинарность" конфига? Что мешает тебе стандартизовать формат текстового конфига и гонять запросы по нему?
WF>Ну, пусть это будет XML. Запросы — XPath, редактирование в GUI делается на основе схемы.
WF>Зачем бинарность-то нужна?
А зачем тебе текстовость нужна, если ты все равно будешь использовать специальный инструмент для его редактирования и навигации по нему? У твоего компьютера слишком много свободных ресурсов? (только не бейте меня ногами за это вульгарное слово — производительность )
Я не знаю как остальные, но лично меня напрягает, когда моя система скрипит под тяжестью какой-нибудь программулины с моднейшими XML-ными хранилищами данных.
Оперативки мало, говорите? Нет, вы серьезно уверены, что гиг оперативки — это мало?
то есть ты уже знаешь, какой на самом деле параметр тебе нужен
ну а все таки? Как бы ты извлек список расширений, которые подключены к серверу MySQL?
E>Ну мы тут не только про базы данных говорили E>Но, с другой стороны, это программисту легко sql-ный select слабать, чтобы по нескольким таблицам выборку сделать. А вот имеет ли смысл требовать того же от администратора?
Только не говори, что регулярные выражения проще, чем SQL.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, eao197, Вы писали:
E>>grep -r "0" *.cfg | grep "reconnect-timeout"
Д>то есть ты уже знаешь, какой на самом деле параметр тебе нужен
Ну да. Более того, в своих конфигах я даже знаю, как этот параметр будет записан, поэтому могу и без конвейера grep-ов обойтись.
Д>ну а все таки? Как бы ты извлек список расширений, которые подключены к серверу MySQL?
Никогда не работал с MySQL, ничего не могу сказать по этому поводу.
E>>Ну мы тут не только про базы данных говорили E>>Но, с другой стороны, это программисту легко sql-ный select слабать, чтобы по нескольким таблицам выборку сделать. А вот имеет ли смысл требовать того же от администратора?
Д>Только не говори, что регулярные выражения проще, чем SQL.
Не проще, однозначно. Хотя и SQL с его join-ами подводные камни имеет. Ну и кроме того, regex мощнее, чем LIKE в SQL.
Но grep уж точно на таком огромном количестве платформ есть, что и не сосчитаешь с ходу.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>(только не бейте меня ногами за это вульгарное слово — производительность )
И какой же выигрыш в производительности приложения планируется получить, даже если уменьшить время чтения конфига в 100 раз?
Д>Я не знаю как остальные, но лично меня напрягает, когда моя система скрипит под тяжестью какой-нибудь программулины с моднейшими XML-ными хранилищами данных.
Пожалуйста, не надо путать конфигурацию приложения и данные, обрабатываемые приложением. Это разные вещи, хотя граница иногда и размыта.
Здравствуйте, Дарней, Вы писали:
Д>А зачем тебе текстовость нужна, если ты все равно будешь использовать специальный инструмент для его редактирования и навигации по нему?
Уже сто раз объясняли. diff, grep, find, patch, awk, vim, и.т.д. Мне так никто и не объяснил, зачем от них отказываться. Пусть даже и при наличии "специальных инструментов".
Например, ты сделаешь для своих конфигов аналог трехточечного diff-а (который используется в CVS)? Или аналог cvs blame (не знаю, правда, зачем ).
А все эти проблемы с "эскейпингом", "способ записи" — надуманны. В конфиге про который я ничего не знаю и искать что-либо смысла нет.
Д>У твоего компьютера слишком много свободных ресурсов? (только не бейте меня ногами за это вульгарное слово — производительность )
Основные ресурсы, как правило, идут отнюдь не на разбор конфига.
Д>Я не знаю как остальные, но лично меня напрягает, когда моя система скрипит под тяжестью какой-нибудь программулины с моднейшими XML-ными хранилищами данных.
Здравствуйте, А почему вы спрашиваете, Вы писали:
ПК>>Вопрос такой: как ты относишься к выбору между XML, INI-подобными файлами и custom formats?
АПВ>К XML'ю для конфигов я отношусь скептически, все-таки XML весьма условно human readable и практически не human writable — уж больно многословен. Что касается INI-style vs. все остальное, то тут у меня явных предпочтений нет. Главное, чтобы "костюмчик сидел" — чтобы язык конфига был адекватен задаче. В простых случаях INI будет достачно, в случаях посложней, должен окупиться собственный формат.
Собственно, вот и ответ любителям использовать XML по любому чиху. Надо уметь правильно расставлять приоритеты между удобством пользования и удобством разработки.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
E>>Ну вот мне вообще интересно, как в реестре сохранять структуры, которые в конфиге легко можно задавать повторяющимися тегами: E>>
E>>{operator
E>> {id ...}
E>> ...
E>>}
E>>
LCR>Немного не в тему, такой вопрос: а чем был обусловлен выбор фигурной скобки вместо круглой?
На меня в свое время произвел впечатление язык Curl. Настолько, что я сделал для себя библиотеку, которую использую для хранения конфигов в синтаксисе Curl-а.
Но здесь эту тему уже обсуждали: Формат конфигов
Здравствуйте, eao197, Вы писали:
E>Собственно, если попробовать развить идею дальше, то можно вполне представить себе C++ приложение, которое собирается Ruby (Python, Tcl/Tk) скриптом в единое целое.
В принципе идея "клеевых" языков в общем и целом не нова, согласен.
Java та же если не выпендриваться в стиле "все на java" вельми как хороша для этого.
В моем конкретном случае (например BlockNote) получается целый класс функций
которые просятся в скрипт. Например формирование TOC по набору H1-H6 тэгов в документе.
Еще одна пользительная фенечка — code coloriser встроенный в редактор для разных типов
исходников и пр. Собственно модули разбора синтаксиса разных языков и есть
части config'a. Пользователи часто просят всякие мелочи, но ломает же ведь каждый раз суровым програмизмом заниматься.
eao197,
LCR>>Немного не в тему, такой вопрос: а чем был обусловлен выбор фигурной скобки вместо круглой?
E>На меня в свое время произвел впечатление язык Curl. Настолько, что я сделал для себя библиотеку, которую использую для хранения конфигов в синтаксисе Curl-а. E>Но здесь эту тему уже обсуждали: Формат конфигов
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
E>>На меня в свое время произвел впечатление язык Curl. Настолько, что я сделал для себя библиотеку, которую использую для хранения конфигов в синтаксисе Curl-а.
LCR>Интересно. Только вот ещё странно: произвёл впечатление Curl, а пишешь на Сипласплас
Да ничего странного
Во-первых, Curl задумывался как новый язык для Web-разработки. Ну и для GUI он мог бы подойти. А я сейчас больше по серверным приложениям из области телекоммуникаций специализируюсь.
Во-вторых, Curl не оправдал возлагавшихся на него надежд. Несколько лет назад я слышал, что Curl Corporation был скуплен на корню японцами, которые успешно его применяют для создания внутрикорпоративных Intranet систем. Такой узкоспециализированный нишевой продукт получился.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, А почему вы спрашиваете, Вы писали:
АПВ>И какой же выигрыш в производительности приложения планируется получить, даже если уменьшить время чтения конфига в 100 раз?
а скорость чтения рабочих данных приложения?
Д>>Я не знаю как остальные, но лично меня напрягает, когда моя система скрипит под тяжестью какой-нибудь программулины с моднейшими XML-ными хранилищами данных.
АПВ>Пожалуйста, не надо путать конфигурацию приложения и данные, обрабатываемые приложением. Это разные вещи, хотя граница иногда и размыта.
две стороны одной медали Вса аргументы, которые можно высказать про один из них, так же можно перенести и на другой.
Здравствуйте, eao197, Вы писали:
E>Ну да. Более того, в своих конфигах я даже знаю, как этот параметр будет записан, поэтому могу и без конвейера grep-ов обойтись.
вот-вот. Нужно иметь информацию не только о нужных тебе параметрах, но и о том, как они представлены в данном конфиге (уточню — каждом данном конфиге).
E>Никогда не работал с MySQL, ничего не могу сказать по этому поводу.
аналогичный пример можно привести про любую другую прогу, у которой параметров больше, чем пара десятков
E>Не проще, однозначно. Хотя и SQL с его join-ами подводные камни имеет. Ну и кроме того, regex мощнее, чем LIKE в SQL.
Просто потому, что у регэксов нет никаких возможностей строить более сложные запросы, чем плоский поиск по файлу (есть еще конечно look ahead/look behind, но пользы от них не так уж много. А уж в применении они точно куда сложнее, чем join)
E>Но grep уж точно на таком огромном количестве платформ есть, что и не сосчитаешь с ходу.
Здравствуйте, WFrag, Вы писали:
WF>Например, ты сделаешь для своих конфигов аналог трехточечного diff-а (который используется в CVS)? Или аналог cvs blame (не знаю, правда, зачем ).
Ради более продвинутых инструментов, например.
WF>А все эти проблемы с "эскейпингом", "способ записи" — надуманны. В конфиге про который я ничего не знаю и искать что-либо смысла нет.
Если ты лично уже натренировался так, что у тебя это на уровне подсознания происходит — это не значит, что проблемы нет вообще. Меня например это напрягает.
WF>Тю. Так то данные.
А что, для них возможность чтения человеком и ручного восстановления не нужны совсем?
Здравствуйте, Дарней, Вы писали:
Д>Ради более продвинутых инструментов, например.
"Продвинутые" в каком плане? Более универсальные, более мощные или какие-то еще?
Тем более, я повторю, я же не говорю, что нужно отказываться от более "продвинутых" утилит.
Д>Если ты лично уже натренировался так, что у тебя это на уровне подсознания происходит — это не значит, что проблемы нет вообще. Меня например это напрягает.
Что на уровне подсознания? Чтение документации перед тем, как что-то пытаться поправить? Согласен, принцип "поставим галочку, а потом посмотрим, что произойдет" в случае ручного редактирования текстовых конфигов мало применим (однако никто не мешает пользоваться "высокоуровневыми" средствами, если они есть, конечно, но это уже другой вопрос ).
WF>>Тю. Так то данные.
Д>А что, для них возможность чтения человеком и ручного восстановления не нужны совсем?
Это зависит от типа данных. Базу данных платежных транзакций или сообщения RSDN@Home я вряд ли смогу восстановить вручную. Другие задачи, другие требования
Здравствуйте, WFrag, Вы писали:
WF>"Продвинутые" в каком плане? Более универсальные, более мощные или какие-то еще?
и то, и другое, я думаю
WF>Что на уровне подсознания? Чтение документации перед тем, как что-то пытаться поправить? Согласен, принцип "поставим галочку, а потом посмотрим, что произойдет" в случае ручного редактирования текстовых конфигов мало применим (однако никто не мешает пользоваться "высокоуровневыми" средствами, если они есть, конечно, но это уже другой вопрос ).
Чтение документации, чтобы посмотреть, какие разделители надо ставить в списке значений, например.
WF>Это зависит от типа данных. Базу данных платежных транзакций или сообщения RSDN@Home я вряд ли смогу восстановить вручную. Другие задачи, другие требования
То есть для конфигов надо обязательно иметь возможность восстанавливать их вручную после аппаратного сбоя, а для рабочих данных нет? А я всегда думал, что данные ценнее, чем настройки проги
Не говоря уже о том, что конфиги меняются относительно редко, и бэкап на 99,99% решит проблему их восстановления. А вот для рабочих данных — нет.
Здравствуйте, Дарней, Вы писали:
Д>и то, и другое, я думаю
Такого не бывает
Например, я часто в комментариях оставляю куски конфига. Или пояснения. Очень полезная возможность. И основана она именно на том, что в plain-text конфиги (как правило) можно вставлять любой текст (в комментарии), без учета специфики конфига. А потом изменением пары символов включать или выключать ту или иную часть.
Д>Чтение документации, чтобы посмотреть, какие разделители надо ставить в списке значений, например.
Ой, да не смеши. Это пять-десять минут максимум. Полное осознание конфига того же Апача — час как минимум.
Д>То есть для конфигов надо обязательно иметь возможность восстанавливать их вручную после аппаратного сбоя, а для рабочих данных нет? А я всегда думал, что данные ценнее, чем настройки проги Д>Не говоря уже о том, что конфиги меняются относительно редко, и бэкап на 99,99% решит проблему их восстановления. А вот для рабочих данных — нет.
Ну я же сказал — данные как правило гораздо сложнее вручную восстановить. Только бэкап (хотя, для конфигов та же ерунда на самом деле)
Здравствуйте, WFrag, Вы писали:
WF>Такого не бывает
я надеюсь, что все-таки бывает
WF>Например, я часто в комментариях оставляю куски конфига. Или пояснения. Очень полезная возможность. И основана она именно на том, что в plain-text конфиги (как правило) можно вставлять любой текст (в комментарии), без учета специфики конфига. А потом изменением пары символов включать или выключать ту или иную часть.
ну.. для базы данных это чуть сложнее, но никаких принципиальных проблем тут нет.
WF>Ой, да не смеши. Это пять-десять минут максимум. Полное осознание конфига того же Апача — час как минимум.
когда думаешь только о решении своей задачи, даже 5 минут — это неприятно. Здесь 5 минут, там 5 минут — потом уже и забудешь, чего сначала хотел
WF>Ну я же сказал — данные как правило гораздо сложнее вручную восстановить. Только бэкап (хотя, для конфигов та же ерунда на самом деле)
ну вот видишь не так уж и важна такая возможность. тем более, что другими средствами эту задачу можно решить куда эффективнее
Здравствуйте, Дарней, Вы писали: WF>>А что считать "приложением"? Как отделить одно приложение от другого? Д>например — процесс, запущенный из заданного бинарного файла
Идея, конечно, замечательная. Вот только проблема не имеет никакого отношения ни к ФС, ни к реестру. Проблема — в самой системе безопасности. Когда проектировалась NT, никто не предполагал нужды в CAS. Времена изменились; теперь все не так, как раньше. Модель безопасности в управляемой среде значительно сложнее, и она как раз включает раздачу привилегий не только пользователям, но и коду. Причем от самих ресурсов в общем-то ничего умного и не надо. Все проверяет рантайм.
З.Ы. Кое-где в нативной винде тем не менее применяются проверки запускающего приложения. Например, некоторые функции WinLogon можно запускать только из логон-сервиса. Можно написать свою GINA DLL, которая получит доступ к этим функциям, благодаря тому, что ее загрузят в адресное пространство соответствующего процесса. Но написать свое приложение, которое будет обращаться к этим функциям мимо стандартного сервиса, не выйдет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>З.Ы. Кое-где в нативной винде тем не менее применяются проверки запускающего приложения.
Нигде и никогда. Это вообще возможно только в управляемом коде.
S> Например, некоторые функции WinLogon можно запускать только из логон-сервиса.
Нет. Есть понятие привелегий. С каждым процессом или потоком ассоциируется токен защиты. Некоторые учетные записи имеют больше привелегий. Некоторые меньше. Некоторые привелегии по умолчанию выключены. Некоторые нет. От этого изависит что и где можно вызывать. У учетной записи System есть некоторые привелегии недоступные другим. По этому некоторые вызовы можно сделать только из под нее. Ну, а с нулевого кольца защиты вообще нет ничего недостижимого. Тот же СофтАйс внаглую тормозит любое виндовое приложение и лезет в память. Я как-то Квэйк3 тормозил во время игры.
S> Можно написать свою GINA DLL, которая получит доступ к этим функциям, благодаря тому, что ее загрузят в адресное пространство соответствующего процесса. Но написать свое приложение, которое будет обращаться к этим функциям мимо стандартного сервиса, не выйдет.
Были бы функции доступны. А при желании вызвать можно хоть черта лысого.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Нигде и никогда. Это вообще возможно только в управляемом коде.
Да, виноват. Похоже, я что-то неправильно понял, когда занимался этим в последний раз. Сейчас перечитал — достаточно иметь привилегию SeTcbPrivilege.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Дарней, Вы писали:
E>>Ну да. Более того, в своих конфигах я даже знаю, как этот параметр будет записан, поэтому могу и без конвейера grep-ов обойтись.
Д>вот-вот. Нужно иметь информацию не только о нужных тебе параметрах, но и о том, как они представлены в данном конфиге (уточню — каждом данном конфиге).
Свежий пример: потребовалось мне сегодня просмотреть, какие IP адреса разные компоненты используют. У каждого компонента собственная структура конфига. Общее только то, что IP адрес записывается в теге {ip}. Для получения списка всех IP я просто зашел в каталог с конфигами, выполнил поиск:
grep -r -E "\{ip[[:space:]]" .
и получил все, что мне нужно. Совершенно не заботясь о том, для каких тегов {ip} является дочерним в каждом из конфигов. Более того, даже если бы я не знал, в каких именно тегах записываются IP-шники, я мог запустить grep с другим regexp-ом:
А вот если бы конфигурация хранилась в SQL БД и каждый компонент хранил бы настройки в своей таблице, как бы мне тогда пришлось получать список IP-шников (даже если в каждой таблице IP хранится в столбце с именем "IP")?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Свежий пример: потребовалось мне сегодня просмотреть, какие IP адреса разные компоненты используют. У каждого компонента собственная структура конфига. Общее только то, что IP адрес записывается в теге {ip}. Для получения списка всех IP я просто зашел в каталог с конфигами, выполнил поиск: E>
E>grep -r -E "\{ip[[:space:]]" .
E>
E>и получил все, что мне нужно. Совершенно не заботясь о том, для каких тегов {ip} является дочерним в каждом из конфигов. Более того, даже если бы я не знал, в каких именно тегах записываются IP-шники, я мог запустить grep с другим regexp-ом: E>
E>А вот если бы конфигурация хранилась в SQL БД и каждый компонент хранил бы настройки в своей таблице, как бы мне тогда пришлось получать список IP-шников (даже если в каждой таблице IP хранится в столбце с именем "IP")?
А вот если бы в одном конфиге тэг назывался host_address, а не ip? А сам адрес записывался бы в шестнадцатеричной форме? Как бы тебе тогда пришлось его получать?
Здравствуйте, Дарней, Вы писали:
E>>А вот если бы конфигурация хранилась в SQL БД и каждый компонент хранил бы настройки в своей таблице, как бы мне тогда пришлось получать список IP-шников (даже если в каждой таблице IP хранится в столбце с именем "IP")?
Д>А вот если бы в одном конфиге тэг назывался host_address, а не ip? А сам адрес записывался бы в шестнадцатеричной форме? Как бы тебе тогда пришлось его получать?
Хранить IPv4 сразу в шестнадцатиричном виде? Это оригинально
А такое вообще бывает?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Хранить IPv4 сразу в шестнадцатиричном виде? Это оригинально E>А такое вообще бывает?
Ну если очень хочется, то можно.
C:\>ping 2130706433
Обмен пакетами с 127.0.0.1 по 32 байт:
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Статистика Ping для 127.0.0.1:
Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время передачи и приема:
наименьшее = 0мс, наибольшее = 0мс, среднее = 0мс
C:\>ping 0x7F000001
Обмен пакетами с 127.0.0.1 по 32 байт:
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Статистика Ping для 127.0.0.1:
Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время передачи и приема:
наименьшее = 0мс, наибольшее = 0мс, среднее = 0мс
Но рассчитывать на такую запись в конфигах я бы не стал. Если администратор такое сделал, то ССЗБ. Но вот если речь о данных получаемых от пользователя, то на такое надо проверять обязательно.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Дарней, Вы писали:
E>>>А вот если бы конфигурация хранилась в SQL БД и каждый компонент хранил бы настройки в своей таблице, как бы мне тогда пришлось получать список IP-шников (даже если в каждой таблице IP хранится в столбце с именем "IP")?
Д>>А вот если бы в одном конфиге тэг назывался host_address, а не ip? А сам адрес записывался бы в шестнадцатеричной форме? Как бы тебе тогда пришлось его получать?
E>Хранить IPv4 сразу в шестнадцатиричном виде? Это оригинально E>А такое вообще бывает?
Суть вопроса была не в этом
... << RSDN@Home 1.2.0 alpha rev. 614>>
играет: Валерий Меладзе — [Настоящее...] Ночь накануне Рождества [foobar2000 v0.8.3]
Здравствуйте, ironwit, Вы писали:
E>>>>А вот если бы конфигурация хранилась в SQL БД и каждый компонент хранил бы настройки в своей таблице, как бы мне тогда пришлось получать список IP-шников (даже если в каждой таблице IP хранится в столбце с именем "IP")?
Д>>>А вот если бы в одном конфиге тэг назывался host_address, а не ip? А сам адрес записывался бы в шестнадцатеричной форме? Как бы тебе тогда пришлось его получать?
E>>Хранить IPv4 сразу в шестнадцатиричном виде? Это оригинально E>>А такое вообще бывает? I>Суть вопроса была не в этом
А в чем?
Если какой-то IP задан в шестнадцатиричном виде, то:
Дарней wrote: > Здравствуйте, eao197, Вы писали: > > E>Сразу история вспоминается, с которой мне довелось столкнуться. Мои >[quote skipped] > оказывается. А текстовый редактор -- он практически везде есть. > > Ну это опять же вопрос доступности инструментов. А если стандартизовать > единый формат для бинарных конфигов и в каждом дистрибутиве будет > удобный редактор/навигатор по нему?
Текстовых форматов от и до, но для любого можно за малое время
подстроить ViM. Единый бинарный формат — хоть один пример формата (не
обязательно бинарного), который не распался, не разросся в два-десять
раз и не сильно менялся, можно? Shell script — не уверен..
> E>Но вот как быть с поиском по реестру, например? > > Не совсем понял, что ты имеешь в виду.
Сохранить egrep "<awful expression>" < "<file name>" в скрипте не
вопрос. А вот сохранить выражение для поиска по реестру — нужны утилиты
(хорошие, нестандартные) для работы с реестром.
eao197 wrote: > Д>Только не говори, что регулярные выражения проще, чем SQL. > > Не проще, однозначно. Хотя и SQL с его join-ами подводные камни имеет. > Ну и кроме того, regex мощнее, чем LIKE в SQL. > Но grep уж точно на таком огромном количестве платформ есть, что и не > сосчитаешь с ходу.
Здравствуйте, raskin, Вы писали:
R>Текстовых форматов от и до, но для любого можно за малое время R>подстроить ViM. Единый бинарный формат — хоть один пример формата (не R>обязательно бинарного), который не распался, не разросся в два-десять R>раз и не сильно менялся, можно? Shell script — не уверен..
R>Сохранить egrep "<awful expression>" < "<file name>" в скрипте не R>вопрос. А вот сохранить выражение для поиска по реестру — нужны утилиты R>(хорошие, нестандартные) для работы с реестром.
Я тебе про Фому, а ты мне про Ерему.
Если сейчас нет подходящих инструментов — это не значит, что их вообще не может быть.
А с чего ты взял, что цифр должно быть ровно 8?
И еще остается вариант ping 2130706433
И кто вообще сказал, что в конфиге хранятся только айпишники, но не DNS имена?
E>А я так и не понял, как аналогичный поиск сделать в SQL БД. Чтобы сразу по всем таблицам с конфигурациями.
Указать селект по множеству таблиц в SQL нельзя, насколько мне известно
Чтобы таких проблем не было, можно например установить соглашение, что адреса хостов хранятся всегда в таблице с определенным именем.
Д>А с чего ты взял, что цифр должно быть ровно 8? Д>И еще остается вариант ping 2130706433 Д>И кто вообще сказал, что в конфиге хранятся только айпишники, но не DNS имена?
Я сказал.
E>>А я так и не понял, как аналогичный поиск сделать в SQL БД. Чтобы сразу по всем таблицам с конфигурациями.
Д>Указать селект по множеству таблиц в SQL нельзя, насколько мне известно Д>Чтобы таких проблем не было, можно например установить соглашение, что адреса хостов хранятся всегда в таблице с определенным именем.
Точно также можно договорится, что IP сохраняются в виде ddd.ddd.ddd.ddd:pppp. Имхо, это гораздо проще.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
А программисты всех прог, по конфигам которых ты делаешь поиск, тоже так сказали?
E>Точно также можно договорится, что IP сохраняются в виде ddd.ddd.ddd.ddd:pppp. Имхо, это гораздо проще.
Здравствуйте, Дарней, Вы писали:
E>>Я сказал.
Д>А программисты всех прог, по конфигам которых ты делаешь поиск, тоже так сказали?
Имхо, здесь правила должны диктовать не программисты, а пользователи этих прог. В моем случае это администраторы разрабатываемых мной систем. И я не думаю, что для них будет удобно хранить IP даже в шестнадцатиричном виде, не говоря уже о десятичном. Запись вида ddd.ddd.ddd.ddd:pppp для IP адресов у нас, можно сказать, требование спецификации. Здравый смысл-то, имхо, терять не следует.
E>>Точно также можно договорится, что IP сохраняются в виде ddd.ddd.ddd.ddd:pppp. Имхо, это гораздо проще.
Д>И никаких символических имен?
Опять таки особенность предметной области. Как правило, приходится работать с IP адресами, для которых нет символьных имен.
Ну и я так и не понял, конфиги мы начинаем напрягать по поводу того, что если IP в виде hex, а что если в виде dec, а что если в виде символического имени. Дарней, ты серьезно думаешь, что сложно написать regex, который будет обрабатывать эти ситуации?
А вот что, если все эти вопросы переадресовать к хранению конфигурации в SQL БД?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Запись вида ddd.ddd.ddd.ddd:pppp для IP адресов у нас, можно сказать, требование спецификации.
Я просто говорил о том, что спецификации у разных людей могут различаться. Мы ведь говорили не о поиске в одном конкретном конфиге для одной конкретной программы, не так ли?
E>Ну и я так и не понял, конфиги мы начинаем напрягать по поводу того, что если IP в виде hex, а что если в виде dec, а что если в виде символического имени. Дарней, ты серьезно думаешь, что сложно написать regex, который будет обрабатывать эти ситуации?
Написать — не проблема. А проблема в том, что такой универсальный regex выдаст тебе кучу левой информации в довесок к той, которая тебя интересует. Мне таки крайне интересно посмотреть на regex, который из всех символических имен выделит только те, которые являются именами хостов. Или ты снова вспомнишь про поиск по имени переменной? Ну так здесь тоже куча своих заморочек — имена могут быть не в виде пар имя=значение, а в виде набора элементов XML. Или одного элемента, но со списком значений, разделенных запятыми — список вариантов можно продолжить. Нет даже гарантии, что весь нужный список находится на одной строке.
E>А вот что, если все эти вопросы переадресовать к хранению конфигурации в SQL БД?
Какие вопросы? Сделать выборку по имени поля? Не вижу здесь проблем. Единственная потенциальная проблема — это разные имена в разных конфигах, но ее можно решить с помощью соглашений. Для текстовых конфигов соглашений нужно намного больше.
Здравствуйте, Дарней, Вы писали:
E>>Запись вида ddd.ddd.ddd.ddd:pppp для IP адресов у нас, можно сказать, требование спецификации.
Д>Я просто говорил о том, что спецификации у разных людей могут различаться. Мы ведь говорили не о поиске в одном конкретном конфиге для одной конкретной программы, не так ли?
Не совсем так. В отличии от тебя я не верю в единый удобный для всех и существующий на всех платформах формат конфигов. Поэтому я говорю только о конфигах, с которыми сам работаю. И вот в этом случае grep очень удобный для меня инструмент. Как и для многих других админов/программистов.
Вот что мне кажется необходимым, так это то, чтобы все компоненты одного приложения хранили свои конфиги в одном и том же формате. Вот здесь зоопарка не хочется. И если это текстовый формат, то вопрос о том, XML ли это, ini или lisp-подобный формат -- это уже второй вопрос.
E>>Ну и я так и не понял, конфиги мы начинаем напрягать по поводу того, что если IP в виде hex, а что если в виде dec, а что если в виде символического имени. Дарней, ты серьезно думаешь, что сложно написать regex, который будет обрабатывать эти ситуации?
Д>Написать — не проблема. А проблема в том, что такой универсальный regex выдаст тебе кучу левой информации в довесок к той, которая тебя интересует. Мне таки крайне интересно посмотреть на regex, который из всех символических имен выделит только те, которые являются именами хостов. Или ты снова вспомнишь про поиск по имени переменной? Ну так здесь тоже куча своих заморочек — имена могут быть не в виде пар имя=значение, а в виде набора элементов XML. Или одного элемента, но со списком значений, разделенных запятыми — список вариантов можно продолжить. Нет даже гарантии, что весь нужный список находится на одной строке.
Дело в том, что я знаю с чем работаю. Если я знаю, что у меня в конфигах IP хранятся только в тегах {ip}, то я и пишу regex которому достаточно найти только {ip}. Если имя тега не уникально, но IP хранятся только в ddd.ddd.ddd.ddd:pppp, то я напишу regex для этой маски. Если же могут хранится символьные имена, то и их можно спокойно завернуть в regex.
Главный посыл в том, что я знаю, что я ищу, и я знаю, где я это ищу. Имхо, либой администратор/программист как раз в таких условиях и находится.
E>>А вот что, если все эти вопросы переадресовать к хранению конфигурации в SQL БД?
Д>Какие вопросы?
Хотя бы как хранить IP адреса в таблице БД? В каком именно формате? Если можно хранить и как ddd.ddd.ddd.ddd:pppp и some.host.name:pppp, то как делать поиск по ним?
Д>Сделать выборку по имени поля? Не вижу здесь проблем. Единственная потенциальная проблема — это разные имена в разных конфигах, но ее можно решить с помощью соглашений. Для текстовых конфигов соглашений нужно намного больше.
Ага, соглашения в БД выглядят нормально, а теже самые соглашения в текстовых конфигах -- уже must die!
И как делать поиск, если разные конфиги -- это разные таблицы в БД?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Не совсем так. В отличии от тебя я не верю в единый удобный для всех и существующий на всех платформах формат конфигов.
Вопросы веры — это не по адресу
E>Главный посыл в том, что я знаю, что я ищу, и я знаю, где я это ищу.
И знаешь, как это надо искать.
E>Имхо, либой администратор/программист как раз в таких условиях и находится.
Не любой. Меня например уже достало, что при использовании каждой новой проги надо разбираться, как именно надо крутить педали у данной модели велосипеда.
E>Хотя бы как хранить IP адреса в таблице БД? В каком именно формате? Если можно хранить и как ddd.ddd.ddd.ddd:pppp и some.host.name:pppp, то как делать поиск по ним?
Для селекта абсолютно монопенисуально, какого типа поле, по которому ты делаешь выборку.
E>Ага, соглашения в БД выглядят нормально, а теже самые соглашения в текстовых конфигах -- уже must die!
Одно дело, когда соглашений одно или два. Другое — когда десять или двадцать.
E>И как делать поиск, если разные конфиги -- это разные таблицы в БД?
Зачем — разные таблицы? Отдельные файлы для каждого конфига.
grep же ищет данные в разных файлах, хотя сами регулярные выражения о файлах ничего не знают? Ну, аналогия понятна.
Здравствуйте, Дарней, Вы писали:
Д>Указать селект по множеству таблиц в SQL нельзя, насколько мне известно Д>Чтобы таких проблем не было, можно например установить соглашение, что адреса хостов хранятся всегда в таблице с определенным именем.
Можно. UNION никто не отменял. Но все равно правила нормализации вынуждают хранить такие настройки в одной таблице. Если, конечно, каждый сервер не использует свои БД.
А соглашение подобное сделать легко, просто указать что имя параметра оканчивается на _IP
что-то типа:
eao197 wrote:
> C>d) Можно устраивать конкурсы obfuscated конфигов. > C>e) Синтаксис, не поддающийся никакому автоматическому разбору. > Вот ты прикалываешься, а если разработка идет на скриптовых языках, то > конфигурирование приложения на самом скриптовом языке может быть > вполне нормальным явлением.
Убью, уроды, руки поотрываю! Уфф... Выговорился.
Сегодня подкинули задачку — написать GUIевый конфигуратор (точнее
web-овский) для крутейшего приложения, в котором конфиги как раз
задаются скриптами (на Python'е). Я уже прикидываю сколько десятков часов потребуется для написания нормального
манипулятора, сохраняющего комментарии и отступы.
Не говоря уж о том, что если кто-то в своей бесконечной мудрости
попробует вставить в конфиг какие-нибудь сторонние команды, то все нафиг
работать перестанет.
Здравствуйте, Cyberax, Вы писали:
>> C>d) Можно устраивать конкурсы obfuscated конфигов. >> C>e) Синтаксис, не поддающийся никакому автоматическому разбору. >> Вот ты прикалываешься, а если разработка идет на скриптовых языках, то >> конфигурирование приложения на самом скриптовом языке может быть >> вполне нормальным явлением.
C>Убью, уроды, руки поотрываю! Уфф... Выговорился.
C>Сегодня подкинули задачку — написать GUIевый конфигуратор (точнее C>web-овский) для крутейшего приложения, в котором конфиги как раз C>задаются скриптами (на Python'е). Я уже прикидываю сколько C>десятков часов потребуется для написания нормального C>манипулятора, сохраняющего комментарии и отступы.
А что, просто высветить multiline-edit-box с текстом конфига нельзя?
C>Не говоря уж о том, что если кто-то в своей бесконечной мудрости C>попробует вставить в конфиг какие-нибудь сторонние команды, то все нафиг C>работать перестанет.
А вот под этим что понимается (под сторонними командами)?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Дарней wrote:
> Написать — не проблема. А проблема в том, что такой универсальный > regex выдаст тебе кучу левой информации в довесок к той, которая тебя > интересует. Мне таки крайне интересно посмотреть на regex, который из > всех символических имен выделит только те, которые являются именами > хостов.
Все еще усложнится, если в конфигах будут ip-адреса в комментариях.
punk4 wrote:
> C>Так именно текстовые конфиги и мешают развитию нормальных средств. > C>Например, webmin у меня несколько раз портил конфиги (путал > комментарии, > C>неправильно форматировал) — с реестром таких проблем бы не было. > Ну вот и подошли, раз писать так писать! Напишите что-то что будет лучше > WEBMIN`а а потом и говорите что он плох.
Computer Management в Винде. Можно менеджерить удаленные компы. Где-то
есть и веб-менеджер.
Ну и в конце-концов можно удаленно подцепиться по WMI к целевому компу
через FAR
eao197 wrote:
> C>Сегодня подкинули задачку — написать GUIевый конфигуратор (точнее > C>web-овский) для крутейшего приложения, в котором конфиги как раз > C>задаются скриптами (на Python'е). Я уже прикидываю сколько > C>*десятков* часов потребуется для написания нормального > C>манипулятора, сохраняющего комментарии и отступы. > А что, просто высветить multiline-edit-box с текстом конфига нельзя?
Нет, так как это должен редактировать достаточно тупой пользователь.
> C>Не говоря уж о том, что если кто-то в своей бесконечной мудрости > C>попробует вставить в конфиг какие-нибудь сторонние команды, то все > нафиг > C>работать перестанет. > А вот под этим что понимается (под сторонними командами)?
punk4 wrote:
>>> C>А если из-за аппаратных проблем упадет сложная файловая система типа >>> C>Reiser4? >>> Если она как-то починится, можно руками поправить файлы. > C>А если не починится? > А если руги и голова ростут от туда от куда надо тогда у тебя как у > нормального > админа ( согласись реанимировать оси дело не програмера а именно > админа) будет > стоять РАИД, будут бэкапы, и много чего еще интересного.
Ну так и реестр прекрасно ложится на заRAIDеный винт.
>>> У меня такое было — упала ext2 (маленький был, глупый). После ремонта >>> больше всего почему-то пострадал конфиг XFree86. Ничего, починил. > C>Ну так с реестром так же. > А на сколько мне извество излюбленный способ починить Вынь — > переустановить её
Насколько мне известно, лучший способ починить Линукс — восстановить его
из бэкапа.
Здравствуйте, Cyberax, Вы писали:
>> C>Сегодня подкинули задачку — написать GUIевый конфигуратор (точнее >> C>web-овский) для крутейшего приложения, в котором конфиги как раз >> C>задаются скриптами (на Python'е). Я уже прикидываю сколько >> C>*десятков* часов потребуется для написания нормального >> C>манипулятора, сохраняющего комментарии и отступы. >> А что, просто высветить multiline-edit-box с текстом конфига нельзя?
C>Нет, так как это должен редактировать достаточно тупой пользователь.
Ну тогда вешалка.
Ты привел хороший аргумент в пользу чисто декларативных конфигов -- для скриптовых конфигов такой визуальный редактор написать... Это чуть ли не IDE делать нужно.
Все же скриптовые конфиги требуют гораздо более высокого уровня знаний у администратора.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Логично редактировать конфигурялкой только те куски конфига, которые этой конфигурялкой и были созданы.
Например выделить секцию конфига, куда записывать строчки в удобном для конфигурялки синтаксисе, отбить эту секцию предупреждениями, что, мол "don't modify, а если руки чешутся, пиши рядом".
Можно сделать не секцию, а генерить отдельный модуль, который основной конфиг будет import'ить. В общем, главное — это разделить куски модифицируемые человеком и куски модифицируемые конфигурялкой.
Здравствуйте, Дарней, Вы писали:
Д>А вот если бы в одном конфиге тэг назывался host_address, а не ip? А сам адрес записывался бы в шестнадцатеричной форме? Как бы тебе тогда пришлось его получать?
А если бы вчера к вам приходил добрый сисадмин и имена ваших табличе переставил с ног на голову, как бы вы селекты делали??
Здравствуйте, Cyberax, Вы писали:
C>Ну так и реестр прекрасно ложится на заRAIDеный винт.
Да только пишут в реестр все кому не лень туда писать, поставил бряцалку новую, а она тебе написала... Удалил. А она
ничего не удалила за собой ( достаточно частая практика, ув. програмисты ) Отлично!!! Я просто счатстлив.
А текстовый коф...
раздал права на запись root'u а конфижит в общем-то он и %%80 проблем решил, бо ни одна сволочь не запишет ( как в прочем,
и не станет ) ляпать свои настройки в чюжой <что-то>.conf. Естественно что если тебе надоела бряцалка то ты не бродишь по
реестру в поисках ее веток, а просто грохнешь ее конф.
C>Насколько мне известно, лучший способ починить Линукс — восстановить его C>из бэкапа.
Кстати не самый плохой вариант.....
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
punk4 wrote:
> C>Ну так и реестр прекрасно ложится на заRAIDеный винт. > Да только пишут в реестр все кому не лень туда писать, поставил > бряцалку новую, а она тебе написала... Удалил. А она > ничего не удалила за собой ( достаточно частая практика, ув. > програмисты ) Отлично!!! Я просто счатстлив.
У меня в /etc и прочих /lib'ах за годы использования Debian'а скопилась
такая куча мусорных конфигов....
> А текстовый коф... раздал права на запись root'u а конфижит в общем-то > он и %%80 проблем решил, бо ни одна сволочь не запишет ( как в прочем, > и не станет ) ляпать свои настройки в чюжой <что-то>.conf. Естественно > что если тебе надоела бряцалка то ты не бродишь по реестру в поисках > ее веток, а просто грохнешь ее конф.
Угу, оставляя установленые либы в /lib, бинарики разбросаные по всяким
/usr/local/bin и т.п.
А почему вы спрашиваете wrote:
> Логично редактировать конфигурялкой только те куски конфига, которые > этой конфигурялкой и были созданы.
Это 99% конфига (конфиг очень напоминает bind'овский).
> Можно сделать не секцию, а генерить отдельный модуль, который основной > конфиг будет import'ить. В общем, главное — это разделить куски > модифицируемые человеком и куски модифицируемые конфигурялкой.
Не получается — из конфигурялки должно быть доступно ВСЕ.
eao197 wrote:
> C>Нет, так как это должен редактировать достаточно тупой пользователь. > Ну тогда вешалка.
Угу. Проблему решил просто — сдампил все в XML и расставил руками
комментарии из исходного конфига, ну и переделал скрипт конфига на
чтение себя из этого XML
> Все же скриптовые конфиги требуют гораздо более высокого уровня знаний > у администратора.
Здравствуйте, Cyberax, Вы писали:
>> C>Нет, так как это должен редактировать достаточно тупой пользователь. >> Ну тогда вешалка.
C>Угу. Проблему решил просто — сдампил все в XML и расставил руками C>комментарии из исходного конфига, ну и переделал скрипт конфига на C>чтение себя из этого XML
Я бы тоже так сделал. Только на счет XML-я бы подумал
>> Все же скриптовые конфиги требуют гораздо более высокого уровня знаний >> у администратора.
C>Поэтому и неприменимы в энд-юзерских системах.
+1. Но если юзер не видит тела самого конфига, то что XML, что YAML -- нет разницы.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>У меня в /etc и прочих /lib'ах за годы использования Debian'а скопилась C>такая куча мусорных конфигов....
В /lib-ах конфиги? Обманываешь! Сделай dpkg -S <мусорный файл>. По Debian-овской политике конфиги могут быть только в /etc. Если руками ставил в /lib — ССЗБ.
Что касается /etc то эта проблема обычно решается dpkg --purge <давно_удаленный_пакет>.
C>Угу, оставляя установленые либы в /lib,
В /lib и /usr/lib обычно ставятся только пакеты, которые не имеют привычки за собой что-то удалять в случае их деинсталлирования.
C>бинарики разбросаные по всяким C>/usr/local/bin и т.п.
В /usr/local/bin идут установленные вручную программы. Соответственно, сам намусорил — сам и убирай.
WFrag wrote:
> C>У меня в /etc и прочих /lib'ах за годы использования Debian'а скопилась > C>такая куча мусорных конфигов.... > В /lib-ах конфиги? Обманываешь!
В /lib-ах — либы.
> Что касается /etc то эта проблема обычно решается dpkg --purge > <давно_удаленный_пакет>.
Ошибки в deb'ах встречаются достаточно часто (особенно в unstable/testing).
> C>бинарики разбросаные по всяким > C>/usr/local/bin и т.п. > В /usr/local/bin идут установленные вручную программы. Соответственно, > сам намусорил — сам и убирай.
Ну вот, а говорите реестр... В Винде — сам поставил программу, сам и
убирай за ней. А нормальные проги используют хороший MSI.
eao197 wrote:
> C>Угу. Проблему решил просто — сдампил все в XML и расставил руками > C>комментарии из исходного конфига, ну и переделал скрипт конфига на > C>чтение себя из этого XML > Я бы тоже так сделал. Только на счет XML-я бы подумал
По большому счету, мне без разницы тип конфига — главное, что есть
удобные инструменты для работы с ним. Так что можно было и YAML забабахать.
>>> Все же скриптовые конфиги требуют гораздо более высокого уровня знаний >>> у администратора. > C>Поэтому и неприменимы в энд-юзерских системах. > +1. Но если юзер не видит тела самого конфига, то что XML, что YAML -- > нет разницы.
Здравствуйте, Cyberax, Вы писали:
C>В /lib-ах — либы.
Ну да.
C>Ошибки в deb'ах встречаются достаточно часто (особенно в unstable/testing).
В testing заметных ошибок вроде ни разу не встречал, хотя все бывает. Да и в unstable ошибки такого рода ("потерянные" файлы) я не видел.
Судя по способу сборки deb-ки такая ошибка достигается каким-то нетривиальным путем, т.к deb-ка — это практически обычный архив и все файлы из этого архива отслеживаются пакетным менеджером. Хотя я, конечно, не особо глубоко в этом разбираюсь — может и не так все просто.
Ну да ладно. Не буду углубляться в этот вопрос. У меня мусор вроде не копится.
C>Ну вот, а говорите реестр... В Винде — сам поставил программу, сам и C>убирай за ней.
Не понял. Это разве хорошо? Особенно если программа хлам в реестре оставляет? Каталог я хоть глазами просмотреть могу и dpkg -S натравить на файлы, а в реестре — Руками его не очень-то и почистишь.
C>А нормальные проги используют хороший MSI.
Здравствуйте, Cyberax, Вы писали:
C>WFrag wrote:
>> C>У меня в /etc и прочих /lib'ах за годы использования Debian'а скопилась >> C>такая куча мусорных конфигов.... >> В /lib-ах конфиги? Обманываешь!
C>В /lib-ах — либы.
Ну слава Богу, а то я подумал что у тебя в реестре еще и испольняемые файлы лежат,
докумсенты там разные, и вообще.
>> Что касается /etc то эта проблема обычно решается dpkg --purge >> <давно_удаленный_пакет>. C>Ошибки в deb'ах встречаются достаточно часто (особенно в unstable/testing).
На счет дебиана ничего не знаю, пользую Slackware, так там таких ошибок не замеченно
правда и механизм управления там достаточно простой, без замудрений всяких, зато,
удаляя пакет адаляеш все, при условии что ты ставил именно пакетом а не собирал сорцы,
в противном случаее или ручками или финд и диф используй до и после (кстати очень
и очень удобно, во всяком случае для меня)
C>Ну вот, а говорите реестр... В Винде — сам поставил программу, сам и C>убирай за ней. А нормальные проги используют хороший MSI.
Так извините, почему я должен удалят мусор за какой-то бряцалкой если она использует
MSI. Примеры? Пожалйста, давеча тер ветки Каспера. У него нормальный MSI или нет....
А как предлагаете чистить за офисом, он %%99 пишет далеко не в одно место, а вот текстовы
конфиги достаточно монолитны, ну или разбиваются на несколько файлов и подключаются
друг к другу, да и находятся там куда ты их положил, если программка будет при установке
спрашивать у меня куда ей записать в реестре свои настройки то я после удаления ее так и быть
удалю ее ветки, но ведь таго нет, написали куда захотели и все....
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, Cyberax, Вы писали:
C>Не говоря уж о том, что если кто-то в своей бесконечной мудрости C>попробует вставить в конфиг какие-нибудь сторонние команды, то все нафиг C>работать перестанет.
А ты засунь все в реестр.... Так удобней, так скромней.... А если еще и добавить безопастности,
что в духе СамойЛюбимойКомпании, так вообще никто ничего туда не напишет, да и непрочтет, а есл
постараешь то и сам ничего не запишешь и не прочтеш! C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
punk4 wrote:
> в противном случаее или ручками или финд и диф используй до и после > (кстати очень > и очень удобно, во всяком случае для меня)
regfind, regdiff....
> C>Ну вот, а говорите реестр... В Винде — сам поставил программу, сам и > C>убирай за ней. А нормальные проги используют хороший MSI. > Так извините, почему я должен удалят мусор за какой-то бряцалкой если > она использует > MSI.
Хорошая программа, использующая MSI за собой мусора не оставляет. Ну а
то, что можно писать плохие программы — вроде никто не спорит.
> А как предлагаете чистить за офисом, он %%99 пишет далеко не в одно место
Оффис прекрасно все за собой чистит (что нужно чистить) при удалении.
> а вот текстовы конфиги достаточно монолитны, ну или разбиваются на > несколько файлов и подключаются > друг к другу, да и находятся там куда ты их положил, если программка > будет при установке > спрашивать у меня куда ей записать в реестре свои настройки то я после > удаления ее так и быть > удалю ее ветки, но ведь таго нет, написали куда захотели и все....
Вот бы меня какой deb-пакет спрашивал куда свои настройки пихать...
punk4 wrote:
> C>Не говоря уж о том, что если кто-то в своей бесконечной мудрости > C>попробует вставить в конфиг какие-нибудь сторонние команды, то все > нафиг > C>работать перестанет. > А ты засунь все в реестр....
Я бы с удовольствием, если бы реестр был. Так ведь Linux...
> Так удобней, так скромней.... А если еще и добавить безопастности, что > в духе СамойЛюбимойКомпании, так вообще никто ничего туда не напишет, > да и непрочтет, а есл постараешь то и сам ничего не запишешь и не прочтеш!
Здравствуйте, Cyberax, Вы писали:
C>punk4 wrote:
>> в противном случаее или ручками или финд и диф используй до и после >> (кстати очень >> и очень удобно, во всяком случае для меня)
C>regfind, regdiff....
А вот набрал в консоле, нет у меня такого.... Вопрос. Почему в *nix find и diff есть,
а в Win нет Ваших regfind и ...diff.
C>Хорошая программа, использующая MSI за собой мусора не оставляет. Ну а C>то, что можно писать плохие программы — вроде никто не спорит. C>Оффис прекрасно все за собой чистит (что нужно чистить) при удалении.
Спорить не буду, было чистое предположение... Но каспер все-таки остался,
ща еще по реестру посмотрю..... Пожалуйста — Pervasive SQL. (Получается что
Pervasive дрянная программа.... жаль.... долго использовал, болше не буду.
Дальше смотреть?
C>Вот бы меня какой deb-пакет спрашивал куда свои настройки пихать...
Хе-хе, не знаю как на счет дебиана в целом ( ну не пользуюсь я ей или им ), но:
Кусок ./configure для Squid:
--sysconfdir = /etc/squid --libexecdir = /usr/lib/squid ... и т.д., там еще много можно написать
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, Cyberax, Вы писали:
C>punk4 wrote:
C>Эээ... Прочитайте про права доступа в реестре, плиз. Здесь, например: C>ms-help://MS.MSDNQTR.2005JAN.1033/sysinfo/base/registry_key_security_and_access_rights.htm
А че это такое.... Это ж наверно MSDN (кстати почти маздай). Так у меня его нет, и не будет.
C>Вообще, многим cr00тым Линуксоидам не мешало бы узнать некоторые факты C>про Windows, а не повторять как попугаи "Windows — несекьюрный маздай".
Нет почему же, очень-и очень секретны. Один MS-PAP-CHAP чего стоит.... C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
punk4 wrote:
>>> в противном случаее или ручками или финд и диф используй до и после >>> (кстати очень >>> и очень удобно, во всяком случае для меня) > C>regfind, regdiff.... > А вот набрал в консоле, нет у меня такого....
Ой, а у меня есть. Какое горе...
> Вопрос. Почему в *nix find и diff есть, а в Win нет Ваших regfind и > ...diff.
Значит передо мной галлюцинация? Все, иду к доктору...
> C>Хорошая программа, использующая MSI за собой мусора не оставляет. Ну а > C>то, что можно писать плохие программы — вроде никто не спорит. > C>Оффис прекрасно все за собой чистит (что нужно чистить) при удалении. > Спорить не буду, было чистое предположение... Но каспер все-таки остался, > ща еще по реестру посмотрю..... Пожалуйста — Pervasive SQL. > (Получается что > Pervasive дрянная программа.... жаль.... долго использовал, болше не буду. > Дальше смотреть?
Давайте я вам найду программы для Линукса, который за собой кучу г.
оставляют. Начнем: OpenGroupware. Продолжать?
> C>Вот бы меня какой deb-пакет спрашивал куда свои настройки пихать... > Хе-хе, не знаю как на счет дебиана в целом ( ну не пользуюсь я ей или > им ), но: > Кусок ./configure для Squid: > --sysconfdir = /etc/squid --libexecdir = /usr/lib/squid ... и т.д., > там еще много можно написать
Как мне _автоматически_ собрать Squid со всеми зависимостями? При это
чтобы им можно было из dselect'а управлять.
Здравствуйте, Cyberax, Вы писали:
C>Так PAP или CHAP? Чем вам не нравится MSCHAP v2, например?
И тот и другой, объясните из каких таких соображений необходимо
перебалтать стандартные протоколы PAP CHAP???
Лично у меня был неприятный опыт их использования, когда у провайдера
была NT-я, подключение по диал-ап *nix машины заняло достаточно продолжительное
время, было это пару лет назад, за это время компьютеры поумнели, теперь прощще
но "осадок остался"
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, punk4, Вы писали:
P>>А если бы вчера к вам приходил добрый сисадмин и имена ваших табличе переставил с ног на голову
Д>А что, если добрый сисадмин поставит с ног на голову имена переменных и секций в текстовом конфиге, то прога будет работать?
Если грамотно написанная, она запустится с дефолтными настройками
Здравствуйте, Cyberax, Вы писали:
>> Вопрос. Почему в *nix find и diff есть, а в Win нет Ваших regfind и >> ...diff. C>Значит передо мной галлюцинация? Все, иду к доктору...
Имелось в виду нет по умолчанию...
C>Давайте я вам найду программы для Линукса, который за собой кучу г. C>оставляют. Начнем: OpenGroupware. Продолжать?
А это смотря что Вы понимаете по г. Лично я под г. в реестре понимаю повисшие
ветки от приложений.
C>Как мне _автоматически_ собрать Squid со всеми зависимостями? При это C>чтобы им можно было из dselect'а управлять.
Ну я же говорил — непользую я ДЕБИАН. А следовательно не знаю. Про шлаку могу сказать
только одно — никак. Механизм управления пакетами в яля rpm отсутствует. Есть свой
но достаточно приметивный.
Здравствуйте, punk4, Вы писали:
P>Если грамотно написанная, она запустится с дефолтными настройками
значит, ответ на твой вопрос будет — "аналогично"
хотя, если хорошо подумать — на самом деле грамотно написанная прога должна не проигнорировать наличие непонятных данных в конфиге, а выдать про это осмысленное сообщение и закрыться
punk4 wrote:
> C>Так PAP или CHAP? Чем вам не нравится MSCHAP v2, например? > И тот и другой, объясните из каких таких соображений необходимо > перебалтать стандартные протоколы PAP CHAP???
Мы вроде бы говорим про безопасность. Объясните мне, пожалуйста, чем так
небезопасны и отстойны MSPAP и MSCHAP. Передачу паролей в открытом виде
через PAP уязвимостью не считаем.
> Лично у меня был неприятный опыт их использования, когда у провайдера > была NT-я, подключение по диал-ап *nix машины заняло достаточно > продолжительное > время, было это пару лет назад, за это время компьютеры поумнели, > теперь прощще > но "осадок остался"
А может это у юниксовой машины что-то неправильно настроено было в pppd?
punk4 wrote:
>>> Вопрос. Почему в *nix find и diff есть, а в Win нет Ваших regfind и >>> ...diff. > C>Значит передо мной галлюцинация? Все, иду к доктору... > Имелось в виду нет по умолчанию...
Мало ли чего нет по умолчанию. Инструменты есть, а значит грамотный
администратор их найдет, если нужно.
> C>Давайте я вам найду программы для Линукса, который за собой кучу г. > C>оставляют. Начнем: OpenGroupware. Продолжать? > А это смотря что Вы понимаете по г. Лично я под г. в реестре понимаю > повисшие > ветки от приложений.
Ну вот, а OpenGroupware оставляет г. по всей файловой системе (например,
большая часть файлов ставится в /usr/lib).
> C>Как мне _автоматически_ собрать Squid со всеми зависимостями? При это > C>чтобы им можно было из dselect'а управлять. > Ну я же говорил — непользую я ДЕБИАН. А следовательно не знаю. Про > шлаку могу сказать > только одно — никак.
Ну вот, и в Debian'е — никак. То есть в теории можно настроить каждое
приложение на работу с другим --prefix'ом (например, я таким образом
устанавливал Subversion без админовских прав), но на практике это
бесполезное занятие.
Здравствуйте, Cyberax, Вы писали:
C>Давайте я вам найду программы для Линукса, который за собой кучу г. C>оставляют. Начнем: OpenGroupware. Продолжать?
Здравствуйте, Cyberax, Вы писали:
C>Мы вроде бы говорим про безопасность. Объясните мне, пожалуйста, чем так C>небезопасны и отстойны MSPAP и MSCHAP. Передачу паролей в открытом виде C>через PAP уязвимостью не считаем.
Я не говорю что они небезапастны или отстойны, я говорю о подходе Рейдмонда к безопастности
вообще, изменив довольно стандартные протоколы PAP CHAP ( объясните мне чем они плохи ),
добавив в них пущей секретности.
C>А может это у юниксовой машины что-то неправильно настроено было в pppd?
Смотря с какой стороны посмотреть, после сборки pppd с рядом библиотек все заработало,
но я неуверен что это недостатки pppd. C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
WFrag wrote:
> C>Давайте я вам найду программы для Линукса, который за собой кучу г. > C>оставляют. Начнем: OpenGroupware. Продолжать? > >#find / -mount | wc -l >58227 >#apt-get install opengroupware.org >#apt-get clean >#find / -mount | wc -l >60694 >#apt-get --purge remove <установленные пакеты и зависимости> >#find / -mount | wc -l >58227 > > Ничего не осталось! Пакетный менеджер не при чем!
В последний раз, когда я OPG ставил были только неофициальные ночные
deb-овские билды — релизные билды были "really soon (tm)".
> Правда, я не запускал.
Это целая наука Нужно подправить несколько конфигов, сделать su —
opengroupware, запустить пару утилиток, коннектор, сервер. Ну и еще апач
настроить.
Здравствуйте, Дарней, Вы писали:
Д>значит, ответ на твой вопрос будет — "аналогично" Д>хотя, если хорошо подумать — на самом деле грамотно написанная прога Д>должна не проигнорировать наличие непонятных данных в конфиге, а выдать про это осмысленное сообщение и закрыться
... и если это нармальная прога то она прикинет хватит ли ей данных настроек ( возьмем к примеру Vi ) для нормальной
работы, а при записи состояния запишет корректые в .conf. А вот в случаее с БД записать ничего и никуда вы не сможете
Здравствуйте, punk4, Вы писали:
P>... и если это нармальная прога то она прикинет хватит ли ей данных настроек ( возьмем к примеру Vi ) для нормальной P>работы, а при записи состояния запишет корректые в .conf.
А если юзер просто сделал опечатку в названии параметра? Отправились лесом значит его труды?
P>А вот в случаее с БД записать ничего и никуда вы не сможете
C>Мало ли чего нет по умолчанию. Инструменты есть, а значит грамотный C>администратор их найдет, если нужно.
Без коментария... Не нужно. Не хочу. Не буду. Реестр — ФУ!
C>Ну вот, а OpenGroupware оставляет г. по всей файловой системе (например, C>большая часть файлов ставится в /usr/lib).
Смотря как ставил, я повторюсь если пакетным менеджером он грохнет все,
будь спокоен, кроме пакетов которые кому-то необходимы.... А если собирал
сорцы то и удаляй тем чем собирал, т.е. руками и нечего гнать на OpenGroupware
C>Ну вот, и в Debian'е — никак. То есть в теории можно настроить каждое C>приложение на работу с другим --prefix'ом (например, я таким образом C>устанавливал Subversion без админовских прав), но на практике это C>бесполезное занятие.
Зато конфы находятся у /etc, либы в /lib и т.д.
Здравствуйте, punk4, Вы писали:
P>А потому что имена полей нете....
А ты точно уверен, что это был админ, а не диверсант?
Так можно далеко зайти. Например, заодно exe-шники проги переименовать и в другой каталог положить?
Здравствуйте, Дарней, Вы писали:
Д>А ты точно уверен, что это был админ, а не диверсант? Д>Так можно далеко зайти. Например, заодно exe-шники проги переименовать и в другой каталог положить?
Согласен
Здравствуйте, Cyberax, Вы писали:
C>В последний раз, когда я OPG ставил были только неофициальные ночные C>deb-овские билды — релизные билды были "really soon (tm)".
Ну собственно я это и поставил Никакой кучи г.
Возможно, оно в процессе в /var хлам оставляет, но /var это совсем не /usr/lib
>> Правда, я не запускал.
C>Это целая наука Нужно подправить несколько конфигов, сделать su — C>opengroupware, запустить пару утилиток, коннектор, сервер. Ну и еще апач C>настроить.
Ну это другой вопрос. Я просто усомнился в том, что в /usr/lib остается некий мусор. Возможно, конечно, что эта штука туда в процессе работы зачем-то пишет, но я в этом сомневаюсь.
punk4 wrote:
> C>Ну вот, а OpenGroupware оставляет г. по всей файловой системе > (например, > C>большая часть файлов ставится в /usr/lib). > Смотря как ставил, я повторюсь если пакетным менеджером он грохнет все, > будь спокоен, кроме пакетов которые кому-то необходимы....
"Смотря как ставил, я повторюсь если инсталлятором он грохнет все, будь
спокоен, кроме пакетов которые кому-то необходимы....". Так что ли?
> C>Ну вот, и в Debian'е — никак. То есть в теории можно настроить каждое > C>приложение на работу с другим --prefix'ом (например, я таким образом > C>устанавливал Subversion без админовских прав), но на практике это > C>бесполезное занятие. > Зато конфы находятся у /etc, либы в /lib и т.д.
Ой, меня это так радует, я прямо готов от счастья танцевать....
WFrag wrote:
> C>В последний раз, когда я OPG ставил были только неофициальные ночные > C>deb-овские билды — релизные билды были "really soon (tm)". > Ну собственно я это и поставил Никакой кучи г.
Надо посмотреть. У меня стоит OPG годовой давности — я его трогать боюсь
(вдруг упадет).
> Возможно, оно в процессе в /var хлам оставляет, но /var это совсем не > /usr/lib
Оно _почти_ все ставит в /usr/lib/opengroupware.org/ (причем этот путь
жестко зашит). В доке написано "по историческим причинам"...
Остальное, что не "почти" оседало в разных папках. Может уже и пофиксили
(наконец-то!), надо посмотреть.
> C>Это целая наука Нужно подправить несколько конфигов, сделать su — > C>opengroupware, запустить пару утилиток, коннектор, сервер. Ну и еще > апач > C>настроить. > Ну это другой вопрос. Я просто усомнился в том, что в /usr/lib > остается некий мусор. Возможно, конечно, что эта штука туда в процессе > работы зачем-то пишет, но я в этом сомневаюсь.
О, значит ты просто его не использовал Такая кривая вещь....
punk4 wrote:
> C>Мы вроде бы говорим про безопасность. Объясните мне, пожалуйста, чем > так > C>небезопасны и отстойны MSPAP и MSCHAP. Передачу паролей в открытом виде > C>через PAP уязвимостью не считаем. > Я не говорю что они небезапастны или отстойны, я говорю о подходе > Рейдмонда к безопастности > вообще, изменив довольно стандартные протоколы PAP CHAP ( объясните > мне чем они плохи ), > добавив в них пущей секретности.
И что? Чем они небезопасны и отстойны? Изобретение своих протоколов —
это давняя традиция в IT.
Вообще, система безопасности Винды (токены безопасности, привиллегии и
ACLи) намного лучше примитивной системы безопасности в Линуксе.
> C>А может это у юниксовой машины что-то неправильно настроено было в pppd? > Смотря с какой стороны посмотреть, после сборки pppd с рядом библиотек > все заработало, > но я неуверен что это недостатки pppd.
Ну так тогда и не надо было в пример приводить раз неуверен.
Здравствуйте, Cyberax, Вы писали:
C>И что? Чем они небезопасны и отстойны? Изобретение своих протоколов — C>это давняя традиция в IT.
Не, это в большей степени традиция MS.
C>Вообще, система безопасности Винды (токены безопасности, привиллегии и C>ACLи) намного лучше примитивной системы безопасности в Линуксе.
А как же, например, RSBAC-и всякие? Кому надо — поставит и использует:
Здравствуйте, Cyberax, Вы писали:
C>Вообще, система безопасности Винды (токены безопасности, привиллегии и C>ACLи) намного лучше примитивной системы безопасности в Линуксе.
Ага. Только я не видел ни одной программы, которая ими бы пользовалась. Большое количество базовых функций в виндах содержат отдельный параметр для этих дел. Что-то мне подсказывает, что в 99.9% случаев там передают NULL и не случайно.
Quintanar wrote:
> C>Вообще, система безопасности Винды (токены безопасности, привиллегии и > C>ACLи) намного лучше примитивной системы безопасности в Линуксе. > Ага. Только я не видел ни одной программы, которая ими бы пользовалась.
IIS, MSSQL, ISA Server, Citrix MetaFrame, Oracle. А еще: Miranda,
FireFox, FAR. Достаточно?
> Большое количество базовых функций в виндах содержат отдельный > параметр для этих дел. Что-то мне подсказывает, что в 99.9% случаев > там передают NULL и не случайно.
Да. Однако и большинство Юниксовых программ используют стандартные права
доступа и особо не заморачиваются с ними.
Здравствуйте, Cyberax, Вы писали:
C>punk4 wrote:
>> C>А может это у юниксовой машины что-то неправильно настроено было в pppd? >> Смотря с какой стороны посмотреть, после сборки pppd с рядом библиотек >> все заработало, >> но я неуверен что это недостатки pppd. C>Ну так тогда и не надо было в пример приводить раз неуверен.
Да что вы! Как же как же! Это ж почему с Lin провайдером соединяемся без проблем
( CHAP ) а для Ms нужен MS CHAP.... Странно по меньшей мере, это из рада ваших
улучшений ЩА МЫ ТУТ РЕЕСТР ПРИКРУТИМ! ВСАД! C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
punk4 wrote:
> Да что вы! Как же как же! Это ж почему с Lin провайдером соединяемся > без проблем > ( CHAP ) а для Ms нужен MS CHAP.... Странно по меньшей мере, это из > рада ваших > улучшений ЩА МЫ ТУТ РЕЕСТР ПРИКРУТИМ! ВСАД!
Надоело. Достала ваша неграмотность. Уделил 10 минут поиску в Сети:
Для аутентификации пользователей PPTP может задействовать любой из
протоколов, применяемых для PPP, включая Extensible Authentication
Protocol (EAP), Microsoft Challenge Handshake Authentication Protocol
(MSCHAP) версии 1 и 2, Challenge Handshake Authentication Protocol
(CHAP), Shiva Password Authentication Protocol (SPAP) и Password
Authentication Protocol (PAP). Лучшими считаются протоколы MSCHAP
версии 2 и Transport Layer Security (EAP-TLS), поскольку они
обеспечивают взаимную аутентификацию, т. е. VPN-сервер и клиент
идентифицируют друг друга. Во всех остальных протоколах только сервер
проводит аутентификацию клиентов.
Из PPP-FAQ в Линуксе:
So why didn?t Microsoft just use CHAP with MD5 encryption then? CHAP
does not send the clear text password across the ?wire?. The answer is
that in order to use CHAP protocol, you need the clear text for the
password to be used with the encryption algorithm. You would need to
store this clear text on your disk file. (The pppd process stores it
in the /etc/ppp/chap-secrets file.) Storing a password in clear text
on the disk also violates the requirements for C2 registration.
C> So why didn?t Microsoft just use CHAP with MD5 encryption then? CHAP
C> does not send the clear text password across the ?wire?. The answer is
C> that in order to use CHAP protocol, you need the clear text for the
C> password to be used with the encryption algorithm. You would need to
C> store this clear text on your disk file. (The pppd process stores it
C> in the /etc/ppp/chap-secrets file.) Storing a password in clear text
C> on the disk also violates the requirements for C2 registration.
C>Достаточно?
Нет. Версии фака, pppd и т.п. вещей, а после этого будем разбираться, ибо: http://sysoev.ru/pppd/dial_nt.html C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
А если юзер просто сделал опечатку в названии параметра? Отправились лесом значит его труды?