Cyberax wrote:
>> C>Что такое "специальные утилиты"?
>> regdiff.exe
>
> Ну так diff тогда тоже специальная.

Она записана в POSIX . И меняется реже (несовместимо).
Да, прикалываюсь, хотя мелочь — а неприятно.

Здравствуйте, Cyberax, Вы писали:

C>Врете. У меня настройки монитора в дефолтном конфиге Дебиана лежат в
C>каталоге /etc/apache/../X11! Где же здесь инкапсюляция?

Что-то я не понял логики.

Что с твоей точки зрения "инкапсуляция" (в данной ситуации)?

Здравствуйте, Cyberax, Вы писали:

C>Но вот, к сожалению, не доступны из центрального удобного пользователю
C>средства конфигурирования. Всякие webmin'ы пока еще не очень развиты.

Так вот и развивайте, ведь вам нужны удабные средства, а мне вообще-то
хватает текстовиков.
И вообще кто сказал что-то про пользователя? Пользователю ИМХО незачем знать
токной настройки системы иначе и я и вы и еще куча людей останемся без работы,
а для того чтобы "Ура! Склад!" ему хватает и webmin.

C>Да ничерта оно не приходит быстрее.
Не соглашусь, но испорить не буду у всех поразному.

mibe wrote:

> C>А какая разница? Вы же не сравниваете файлы с помощью прямого чтения
> C>диска, вы пользуетесь API для работы с FS.
> тут у меня скорее претензия, что это API не такое же как для работы с
> ФС. то есть что реестр концептуально похож на ФС, но не является ФС.

API для реестра все же должно отличаться от файловой системы, так как
ключи — это не файлы.

--
С уважением,
Alex Besogonov (alexy@izh.com)

raskin wrote:

>> Еще в Win3.0 для поддержки OLE.
> Но его погром, кажется, не был так опасен.

Там тогда не хранились жизненно важные настройки — они были в ini-файлах
И вот как раз ими очень легко было все порушить.

>>> Но только зачем?
>> Унифицировать формат файлов с конфигами.
> Прыжок — попытка улететь. А если нужны чуть сложнее что делать?

Если ТОЧНО нельзя уложиться в унифицированый формат — то делать свое. Но
почти все известные мне конфиги в него укладываются нормально.

>> У меня используется плугин к FAR'у, который позволяет ходить по реестру
>> (в том числе и удаленному или в виде reg-файла) как по обычному диску.
> Ну, это существует, но Вы же сами говорили "а если ничего не
> прикручивать, а чтоб работало..".

Так редактирование реестра должно быть не обычной операцией для
пользователя. Ну а админ уже будет знать про FAR/TC/....

> Мне удобно не вылезать из ViM. И по файлам ходить им (да, урезано. Но
> иногда достаточно + привычка, что copy
> в командной строке набирать не проблема). И я не уверен, есть ли
> решение для ViM.

Напишите

>> Ну так конфиг-файлы — тоже усложняют создание boot-дискет. Они тогда
>> тоже — лишняя сущность?
> Что надо на Rescue (не привязывая к системе)? Интерпретатор команд,
> драйвера для чтения с разных устройств — возражений нет. Наверное,
> что-то для работы с текстом. Редактор, вроде как. Небольшой. Критичные
> куски настроек. Без перечисленного обойтись — можно, но не хочется. Под
> любой ОС. И тут — что-то для реестра. Содержащее фактически драйвер и
> дублирующее редактор.

Имея все настройки в реестре можно обойтись и без текстового редактора
(см. recovery console в Win2k/xp).

--
С уважением,
Alex Besogonov (alexy@izh.com)

punk4 wrote:

> C>Но вот, к сожалению, не доступны из центрального удобного пользователю
> C>средства конфигурирования. Всякие webmin'ы пока еще не очень развиты.
> Так вот и развивайте, ведь вам нужны удабные средства, а мне вообще-то
> хватает текстовиков.

Так именно текстовые конфиги и мешают развитию нормальных средств.
Например, webmin у меня несколько раз портил конфиги (путал комментарии,
неправильно форматировал) — с реестром таких проблем бы не было.

> И вообще кто сказал что-то про пользователя? Пользователю ИМХО незачем
> знать
> токной настройки системы иначе и я и вы и еще куча людей останемся без
> работы

Простите, моя работа — это не ходить и настраивать Linux'ы. Моя работы —
писать программы, так что без работы я не останусь.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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 после которой в
реестре мусор вместо настроек?

WFrag wrote:

> C>Врете. У меня настройки монитора в дефолтном конфиге Дебиана лежат в
> C>каталоге /etc/apache/../X11! Где же здесь инкапсюляция?
> Что-то я не понял логики.
> Что с твоей точки зрения "инкапсуляция" (в данной ситуации)?

Мне это самому интересно было — откуда берется инкапсюляция в файловой
системе?

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Мне это самому интересно было — откуда берется инкапсюляция в файловой
C>системе?

Еще раз повторю вопрос, я спросил что с твоей точки зрения инкапсуляция в данной ситуации.

Здравствуйте, Cyberax, Вы писали:

C>punk4 wrote:

C>Так именно текстовые конфиги и мешают развитию нормальных средств.
C>Например, webmin у меня несколько раз портил конфиги (путал комментарии,
C>неправильно форматировал) — с реестром таких проблем бы не было.

Ну вот и подошли, раз писать так писать! Напишите что-то что будет лучше
WEBMIN`а а потом и говорите что он плох.

C>Простите, моя работа — это не ходить и настраивать Linux'ы. Моя работы —
C>писать программы, так что без работы я не останусь.

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

WFrag wrote:

> C>Мне это самому интересно было — откуда берется инкапсюляция в файловой
> C>системе?
> Еще раз повторю вопрос, я спросил что с твоей точки зрения
> инкапсуляция в данной ситуации.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, 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)

Здравствуйте, Cyberax, Вы писали:

C>WFrag wrote:

>> C>Инкапсюляция будет, если каждое приложение станет хранить свои данные в
>> C>закрытых от других приложений "черном ящике". А в файловой системе
>> C>инкапсюляции нет.
>> Чем тебе закрытый для чтения другими каталог — не черный ящик?

C>Нет, так как при достаточных правах другая программа может его прочесть.

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

Здравствуйте, Cyberax, Вы писали:

C>Нет, так как при достаточных правах другая программа может его прочесть.

При достаточных правах можно вообще все прочитать. В Java, например, тоже можно сломать инкапсуляцию — прочитать чужое приватное поле. И что?

C>Ну это просто — смотрим PID процесса, пытающегося получить доступ к
C>файлу, а дальше все просто.

И что? Прав-то у тебя все-равно не будет. Если процесс запущен от имени пользователя pupkin и только этому пользователю позволено читать/писать /etc/pupkin то хоть засмотримь на PID, тебе это ничего не даст.

Конечно, такая реализация "identity" приложения довольно примитивна, но это уже другой вопрос. Например, в Java эта самая идентичность может определяться по подписи, расположению класса, и.т.д.

И вообще, я так и не понял, что ты понимаешь под инкапсуляцией. Определение в студию, пожайлуста. Я вообще считаю, что к инкапсуляции это имеет малое отношение. То, что другое приложение может свободно прочитать чужие настройки, на мой взгляд, никак инкапсуляцию не нарушает.

А нарушает ее настройки монитора в конфиге Самбы (например).

Здравствуйте, mibe, Вы писали:

M>тут у меня скорее претензия, что это API не такое же как для работы с ФС. то есть что реестр концептуально похож на ФС, но не является ФС.

Ключевое слово — похож.


Реестр хранит типизированные значения вроде строки и DWORD. Файл же хранит только бинарные денные (даже текстовый) интерпретация которых ведет некое приложение. Другими словами реестр — это скорее БД нежели ФС. Общее у них только иерархичность.

mibe wrote:

> C>API для реестра все же должно отличаться от файловой системы, так как
> C>ключи — это не файлы.
> приведи определение понятия файл, из которого бы это следовало

Файл — нетипизированый набор байт, а ключ реестра имеет тип (DWORD,
ASCIIZ, ...)

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

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 wrote:
> Реестр хранит типизированные значения вроде строки и DWORD. Файл же
> хранит только бинарные денные (даже текстовый) интерпретация которых
> ведет некое приложение. Другими словами реестр — это скорее БД нежели
> ФС. Общее у них только иерархичность.

Это трактовка данных. Всё равно, в DWORD запихивается 4 символа — при
желании. И CPUID этим пользуется. А у файлов бывают расширения. И ФС,
позволяющая ограничить размер файла — не вопрос. Про извращения *nix на
тему "это тоже файл" достаточно упомянуть. Кстати, со специальными
файлами можно сделать не всё, но и то, что можно, облегчает жизнь.