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>файлов с конфигами.
Быстрее текстового конфига с таким же объемом данных — это я конечно не спорю. Но текстовых конфигов такого объема просто не бывает — никто еще не додумался сделать один текстовый конфиг на всю систему, к счастью
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
