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

C>>Она не в стандартной поставке, а в Resource Kit'е.
S>У меня она в совершенно стандартной XP есть. Только что проверил на W2k3 R2 EE, свежепоставленной — есть. Кто-то что-то путает.
да есть она там, есть. и в семерке есть. просто в инете много где написано что она в RK. наверное для win2k.

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

M_>>по-хорошему, да. Именно железом десктоп и сервер и различаются. Ибо у сервера требования скажем, гм..., другие. И если для сервера ты взял низкопробную железку, то ССЗБ
A>про низкопробные это ты ibm-у расскажи, зачем они их в брендовые компы ставят
каждый ССЗБ
ну и все же,у ибм брэндовые компы или таки сервера?

A>готов также выслушать разницу
не знаю, может я заблуждаюсь а назначении серверов.... но, помоему, это такие штуки, которые должны работать 24/7/12 и обслуживать при этом мильон пользователей.... И вроде как матери там чуть другие, и процессоры, и рэйды какие-то ставят (придумали же название, окаянные!)....

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

A>> кстати — а конфиги — это данные или код?
S>Данные.
открой для себя amavis и его конфиг с кусками Perl кода для выполнения в различные моменты времени

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

M_>>>по-хорошему, да. Именно железом десктоп и сервер и различаются. Ибо у сервера требования скажем, гм..., другие. И если для сервера ты взял низкопробную железку, то ССЗБ
A>>про низкопробные это ты ibm-у расскажи, зачем они их в брендовые компы ставят
M_>каждый ССЗБ
M_>ну и все же,у ибм брэндовые компы или таки сервера?
таки не хочу обсуждать, ибо это всё равно будет сведено к "а на нем наклейка 'Vista(2008, 7, etc) compatible' есть?" — на справедливую радость местным линуксоидам как аргумент о "гораздо большем количестве поддерживаемого железа".

A>>готов также выслушать разницу
M_>не знаю, может я заблуждаюсь а назначении серверов.... но, помоему, это такие штуки, которые должны работать 24/7/12 и обслуживать при этом мильон пользователей....
это из определения слова "сервер" что-ли? мы ведь железо обсуждаем, так некоторым "машинам с серверным железом" вообще незачем пользователей пускать.

M>И вроде как матери там чуть другие, и процессоры, и рэйды какие-то ставят (придумали же название, окаянные!)....
у меня дома на десктопе рэйд. и матери двухсокетные тоже никто не мешает в десктоп засунуть ("чем xp-pro тут от xp-home отличается?"). с процами тоже интересно... . от буферизации памяти ОС как-то зависит?

Приветствую, March_rabbit, вы писали:

M> открой для себя amavis и его конфиг с кусками Perl кода для выполнения в различные моменты времени

Открой для себя мой ipt_rules, в котором конфиг является частью скрипта, хотя и лежит отдельно.
Открой для себя rtorerent, в котором в конфиге прописывается код реакции на события.
Открой для себя в конце концов crontab
Дальше что?

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

S> M>Не, не видел Где б найти в этих ваших интернетах пример конфига?
S> Это, кстати, вообще о том, что идея хранить DNS в "конфиге" глубоко порочна. DNS — это база данных.

Это абсолютно не важно — данные все равно должны быть в памяти 24х7, а откуда производится их начальная загрузка пофиг.

Здравствуйте, Anton Batenev, Вы писали:
AB>Это абсолютно не важно — данные все равно должны быть в памяти 24х7, а откуда производится их начальная загрузка пофиг.
Очень странно видеть данное утверждение в контексте обсуждения конфигов. Это раз.
Два — о какой такой "начальной загрузке" тут идёт речь? Я надеюсь, взрослые люди понимают, что не бывает ничего статического — бывает медленно меняющееся динамическое?
Предположим, наш DNS-сервер обслуживает N записей. Каждая запись меняется в среднем раз в год. Новая запись добавляется в среднем трижды в день. Домашнее задание: каково матожидание среднего времени между изменениями конфига, если N = 20000? Домашнее задание повышенной сложности: написать сочинение "допустимо ли в данных условиях полное перечитывание конфига при каждом изменении".

Три — что означает "в памяти"? Вы имеете в виду физическую память? О какой нафиг "физической памяти" можно говорить в наше время? Речь идёт о том, что надо отдавать записи по запросу. Наличие либо отсутствие их в памяти — личное дело реализации. В частности, приличные СУБД точно так же кэшируют данные в памяти, как и любой самописаный config-based демон; в итоге путь запроса внутри машины не проходит через диск — всего лишь пара перемещений данных в памяти, а то и вовсе без перемещений, если драйвер доступа к СУБД умеет пользоваться shared memory. Зато СУБД умеет делать такие вещи, как точечные изменения без перезапуска нахрен всего, и гарантии ACID.

C> C>> Это ты ещё djbdns не видел

C> M>Не, не видел Где б найти в этих ваших интернетах пример конфига?

C> Где-то так:
C>

C>   +ns1.example.com:1.2.3.4:3600
C>   +ns2.example.com:5.6.7.8:3600
C>   +mail.example.com:1.2.3.4:3600
C>   +mail2.example.com:5.6.7.8:3600
C>   +www.example.com:1.2.3.4:3600
C>   +webmail.example.com:1.2.3.4:3600
C>   +anything.example.com:1.2.3.4:3600
C>

жесть

Hello, Sheridan, you write:

S> Приветствую, Mamut, вы писали:

S> M>Sheridan: учись, как надо подкреплять свои слова аргументами

S> Я и так знал и знаю, что прав.

Ты неправ до тех пор, пока не научишься вместо волей предлагать внятные аргументы. В этой подветке прав не ты, а Cyberax

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

S> AB>Это абсолютно не важно — данные все равно должны быть в памяти 24х7, а откуда производится их начальная загрузка пофиг.
S> Очень странно видеть данное утверждение в контексте обсуждения конфигов. Это раз.

Почему же? DNS — яркий пример, когда надо делать так, как удобно, а не так, как "правильно" (особенно при условии, что bind может работать как с текстовыми конфигами, так и с данными из БД, если есть желание).

S> Два — о какой такой "начальной загрузке" тут идёт речь?

О том, что при запуске данные зон читаются в память и живут в ней, пока не придет команда перечитать зону(ы).

S> Предположим, наш DNS-сервер обслуживает N записей.

Зон или все же записей?

S> Каждая запись меняется в среднем раз в год.

Откуда цифра?

S> Новая запись добавляется в среднем трижды в день.

Запись или зона? Откуда цифра?

S> Домашнее задание: каково матожидание среднего времени между изменениями конфига, если N = 20000? Домашнее задание повышенной сложности: написать сочинение "допустимо ли в данных условиях полное перечитывание конфига при каждом изменении".

Не, давай по другому. Представим себе сервер, обслуживающий всю зону RU. Вопросы:

1. Каково количество доменов в зоне RU? (подсказка 2.3 млн. на 3-е сентября 2009)
2. Каков средний размер текстового файла зоны? (подсказка 600-700 байт, можно взять оценку 1КB)
3. Каков итоговый объем данных в текстовом виде? (подсказка ~2.2GB)
4. Сколько времени потребуется серверу при старте, чтобы поднять эти данные в память? Распарсить их во внутреннее представление?
5. Как часто измененные зоны обновляются на сервере (подсказка RU-CENTER 4 раза в сутки)?
6. Сколько зон меняется в сутки?
7. Сколько времени потребуется на то, чтобы перечитать измененные зоны и распарсить их в память?

Ответив на эти вопросы ты получишь ответ на свой вопрос.

S> Три — что означает "в памяти"? Вы имеете в виду физическую память?

Да. Физическую.

S> О какой нафиг "физической памяти" можно говорить в наше время? Речь идёт о том, что надо отдавать записи по запросу. Наличие либо отсутствие их в памяти — личное дело реализации.

Да, под какой нагрузкой умирать — это личное дело реализации.

S> В частности, приличные СУБД точно так же кэшируют данные в памяти, как и любой самописаный config-based демон; в итоге путь запроса внутри машины не проходит через диск — всего лишь пара перемещений данных в памяти

Т.е. на диск СУБД новые данные сбрасывать не обязана?! И инвалидировать кэши при изменении данных...

> , а то и вовсе без перемещений, если драйвер доступа к СУБД умеет пользоваться shared memory. Зато СУБД умеет делать такие вещи, как точечные изменения без перезапуска нахрен всего

А и не надо перезапускать все — достаточно перечитать и распарсить файл измененной зоны размером в 700 байт.

> , и гарантии ACID.

OMG...

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

W1>>Оставим командную строку линуксоидам. Мне, кагбе, удобнее в far выделить нужные каталоги и скопировать их. Удобнее и нагляднее.
S>Прекрасно. Наверное, поможет вот это.

S>Я себя чувствую как-то гугловато. Интересно, каким будет следующий вопрос с очевидным ответом?

Официальных, от майкрософта утилит нет

W1>>Если у вас возникают сомнения в необходимости far и других файловых менеджеров, то прошу пройти к Сергею Зефирову, доказывать вместе с ним ненужность IDE для программирования.

W1>>Мне больше интересно другое. Сейчас 2009 год. Уже. Неужели сложно сделать экспорт реестра в пространство имен файловой системы? То есть будет каталог %windir%\registry, a в нем уже все эти HKEY, за исключением HKCU, ссылка на который есть в домашнем каталоге соответствующего пользователя. Reparse points в фаловой системе есть давным-давно. Очень удобная вещь. Но где символические ссылки на файлы?

S>Символические ссылки? Давно есть, и в семёрке используются в полный рост.
Первый звоночек.
Что они используются я кагбе в курсе.
В висте они используются, есть и для файлов
В хр еще нет, но возможность была, только для каталогов
Не надо подозревать меня в невежестве и отвечать на незаданные вопросы.


W1>>Что-то там майкрософт для виртуализации делает. Virtual PC купили. А что, сложно сделать loop device, как в линуксе, чтобы можно было легко и непринужденно обращаться к дискам виртуальной машины? И на основе "loop device" подключать реестр к файловой системе.
S>Конечно сложно. Не веришь — попробуй сам. TANSTAAFL.

И за солнечный свет тоже платить надо?

Что ж там сложного. Есть какая-то приблуда, то ли filedisk, то ли diskfile. Сам компилировал. Меня удивляет, что такая полезная вещь не входит в стандартную поставку.

W1>>Я занимаюсь эникейством и техподдержкой в мухосранске. Получаю немного больше директора банковского IT отдела в Архангельске, была тут его ветка про кризис и увольнения (это к вопросу — кем лучше работать). Сдохшую ntfs и реестр видел много раз.
S>А. Это многое объясняет.
Ы. Выделенное не читаем?
Есть такое определение профессионализма — "профессионал — это тот, которому за его работу деньги платят". Если же кому чсв важнее денег — его выбор.
Есть вещи, которые можно сделать просто и правильно. А можно заниматься техноонанизмом и сделать сложно. Чем и страдает майкрософт. За что его и хают. И с чего такие как я имеют неплохие деньги.

S>Я тебя уверяю — ты не одинок. К примеру, уборщицы тоже имеют совершенно отдельную точку зрения на то, как должна быть устроена планировка помещения. И электрики предпочли бы все розетки иметь там, где им удобно — на первом этаже, в холле, в распределительном щите.
Второй звоночек. Переход на личности.
Дорогой Синклер, знаком ли ты с таким блоггером, как gans-spb.livejournal.com ? Что он там пишет про программистов? Уж лучше быть менеджером, удовлетворять потребности клиента, чем писать хз что хз зачем. Хотя бы ясна цель и результат.
И для того, чтобы отличить хорошую еду от плохой, не надо быть шеф-поваром.

S>Увы, мир несовершенен, и разработчики винды в первую очередь оптимизируют частые пользовательские сценарии. Редкие ремонтные — не очень. Дешевле платить $50 эникейщику в мухосранске за то, чтобы он освоил утилиту reg, чем инвестировать в эмулятор файлухи и маинтейнить его многие, многие годы.

эмулятор файлухи — очень полезная вещь. А реестр — маздай.

Но я благодарен майкрософту за всю кривизну их решений. Если бы у них все работало и не ломалось, как в MacOS — за что бы мне деньги платили?

Возьмем к примеру, ntfs.
Выключили комп, и тут пропало питание. Просело. Ну бывает такое.
В итоге, при загрузке BSOD — unmoutable boot volume или что-то вроде.
Казалось бы любую (любую, я сказал!) файловую систему можно примонтировать только для чтения. Считать то, что надо. Перемонтировать для чтения и записи. Если не монтируется, вызвать chkdsk и исправить ошибки, перезагрузиться и работать. Но нет же. В итоге мы имеем отдельный класс неполадок. Причем очень веселый класс. Питание всегда может пропасть, не так ли? Оборудование — ненадежно, это аксиома. Итак, у юзера не грузятся винды. Он, подумав немного, грузится с установочного диска виндов и — опа! на разделе видна "неизвестная файловая система". Форматируй заново. Прощай, уродские семейные фотки, базы 1с, заботливо собранные mp3 и прочая хрень.
(не надо мне писать про консоль восстановления, в этом случае не подходит, не работает)
Идиотизм, в общем.

Как там насчет "оптимизации частых пользовательских сценариев"?

А чего стоят вирусы и автозапуск с флэшек... А также возможность положить в папку desktop.ini, чтобы при каждом входе туда проводником что-то исполнялось... Часто ли такое надо в мирных целях?
Техноонанизм как он есть. Фича ради фичи.

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

M>жесть
На самом деле, весьма удобно, когда разберёшься.

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

A>>>про низкопробные это ты ibm-у расскажи, зачем они их в брендовые компы ставят
M_>>каждый ССЗБ
M_>>ну и все же,у ибм брэндовые компы или таки сервера?
A>таки не хочу обсуждать, ибо это всё равно будет сведено к "а на нем наклейка 'Vista(2008, 7, etc) compatible' есть?" — на справедливую радость местным линуксоидам как аргумент о "гораздо большем количестве поддерживаемого железа".

Не не не. Ты не увиливай, ты приводи пример, где IBM ставит на настольные компы W2K8.

Здравствуйте, Ночной Смотрящий, Вы писали:

A>>>>про низкопробные это ты ibm-у расскажи, зачем они их в брендовые компы ставят
M_>>>каждый ССЗБ
M_>>>ну и все же,у ибм брэндовые компы или таки сервера?
A>>таки не хочу обсуждать, ибо это всё равно будет сведено к "а на нем наклейка 'Vista(2008, 7, etc) compatible' есть?" — на справедливую радость местным линуксоидам как аргумент о "гораздо большем количестве поддерживаемого железа".
НС>Не не не. Ты не увиливай, ты приводи пример, где IBM ставит на настольные компы W2K8.
во-во. что я и сказал сообщением ранее да мне пофиг кто куда что ставит — 2к3 там отлично работал (и работает до сих пор). А может я дрова пишу? Мне таки что — покупать сервер? еще раз — может нормальный не слимовый сидюк оказаться в сервере? (я считаю — может, и если ОС, начав ставится с него, вдруг говорит "cdrom not found" — мне очень сильно пофигу, кто что об этом думает; для меня это проблема ОС).

Здравствуйте, waricom-11, Вы писали:
S>>Я себя чувствую как-то гугловато. Интересно, каким будет следующий вопрос с очевидным ответом?

W1>Официальных, от майкрософта утилит нет
Ну и что? Как видим, профессионалов такие мелочи не останавливают.

S>>Символические ссылки? Давно есть, и в семёрке используются в полный рост.
W1>Первый звоночек.
W1>Что они используются я кагбе в курсе.
W1>В висте они используются, есть и для файлов
W1>В хр еще нет, но возможность была, только для каталогов
Была и для файлов. Этой "новой возможности" уже больше 15 лет. Она существует примерно со времён NT 4.0.
Или я что-то неправильно понял?
W1>Не надо подозревать меня в невежестве и отвечать на незаданные вопросы.
W1>И за солнечный свет тоже платить надо?
А то. На этот вопрос отвечать подробно? Или ваше невежество не распространяется на информацию о солнечных ожогах, выгорании красителей и фоторазрушении материалов?

W1>Что ж там сложного. Есть какая-то приблуда, то ли filedisk, то ли diskfile. Сам компилировал. Меня удивляет, что такая полезная вещь не входит в стандартную поставку.
Это ты про ту, которая iso монтирует? Это, мягко говоря, отличается по функционалу от RW файлухи, которая поддерживает security и audit. Нет, я не профессионал в области low-level винды. Но примерное представление о сложности всякого имею. И о стандартном ответе на вопрос "почему X нет в стандартной поставке" тоже.
S>>А. Это многое объясняет.
W1>Ы. Выделенное не читаем?
W1>Есть такое определение профессионализма — "профессионал — это тот, которому за его работу деньги платят". Если же кому чсв важнее денег — его выбор.
Я не понял. У кого-то есть желание помериться зарплатой? Предлагаю в эти игры не играть. В целях сохранения вашего чсв.

W1>Есть вещи, которые можно сделать просто и правильно. А можно заниматься техноонанизмом и сделать сложно. Чем и страдает майкрософт. За что его и хают. И с чего такие как я имеют неплохие деньги.


W1>Второй звоночек. Переход на личности.
Здесь нет никакого перехода на личности. Я всего лишь объясняю, что должность неизбежно оказывает влияние на точку зрения. Именно поэтому программистам крайне противопоказано самостоятельное проектирование пользовательских интерфейслов.

W1>Дорогой Синклер, знаком ли ты с таким блоггером, как gans-spb.livejournal.com ? Что он там пишет про программистов? Уж лучше быть менеджером, удовлетворять потребности клиента, чем писать хз что хз зачем. Хотя бы ясна цель и результат.
Я знаком. Он для вас что, авторитет? Сочуствую.

W1>Но я благодарен майкрософту за всю кривизну их решений. Если бы у них все работало и не ломалось, как в MacOS — за что бы мне деньги платили?

W1>Как там насчет "оптимизации частых пользовательских сценариев"?
Ещё раз поясняю, медленно: 99% пользователей никогда в жизни не сталкиваются с вышеописанным. Вот лично у меня с 20 лет и до сих пор ни разу не дохла NTFS. Питание — пропадало. Десятки раз. А реестр — не бился, и файлуха не дохла. Просто лично вас приглашают только тогда, когда chkdsk уже не помог. Поэтому и складывается искажённое представление о частоте сценариев.

W1>Техноонанизм как он есть. Фича ради фичи.
Где-то винда переусложнена. Это правда. Большинство вещей там сделаны для того, чтобы поднять вторичный рынок. Второй такой системы, настолько дружественной к 3rd-party разработчику, нет. В связи с чем и имеем это разнообразие софта под винду, который столь разнообразно и эффектно глючит.

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

AB>Почему же? DNS — яркий пример, когда надо делать так, как удобно, а не так, как "правильно" (особенно при условии, что bind может работать как с текстовыми конфигами, так и с данными из БД, если есть желание).
По-прежнему не понимаю этой сложной фразы. Можно для тупых расшифровать, где тут "удобно", и где "правильно"?

AB>О том, что при запуске данные зон читаются в память и живут в ней, пока не придет команда перечитать зону(ы).
Это тоже весьма спорная реализация.

S>> Предположим, наш DNS-сервер обслуживает N записей.

AB>Зон или все же записей?
Записей. Это для упрощения. Чтобы не вычислять "средний размер зоны", который сильно плавает.

AB>Откуда цифра?
С потолка, завышена.
S>> Новая запись добавляется в среднем трижды в день.
AB>Запись или зона? Откуда цифра?
Запись. Цифра — с потолка, сильно занижена (тот же dotster регистрирует новые домены со скоростью существенно выше)

AB>Не, давай по другому. Представим себе сервер, обслуживающий всю зону RU. Вопросы:

AB>1. Каково количество доменов в зоне RU? (подсказка 2.3 млн. на 3-е сентября 2009)
AB>2. Каков средний размер текстового файла зоны? (подсказка 600-700 байт, можно взять оценку 1КB)
AB>3. Каков итоговый объем данных в текстовом виде? (подсказка ~2.2GB)
AB>4. Сколько времени потребуется серверу при старте, чтобы поднять эти данные в память? Распарсить их во внутреннее представление?
AB>5. Как часто измененные зоны обновляются на сервере (подсказка RU-CENTER 4 раза в сутки)?
AB>6. Сколько зон меняется в сутки?
AB>7. Сколько времени потребуется на то, чтобы перечитать измененные зоны и распарсить их в память?

AB>Ответив на эти вопросы ты получишь ответ на свой вопрос.
Ну, так если все ответы уже есть, то в чём прикол?

AB>Да. Физическую.
S>> О какой нафиг "физической памяти" можно говорить в наше время? Речь идёт о том, что надо отдавать записи по запросу. Наличие либо отсутствие их в памяти — личное дело реализации.
AB>Да, под какой нагрузкой умирать — это личное дело реализации.
То есть кому-то здесь непонятно, что современная ОС не даст тебе гарантию наличия в физической памяти всех 2.2 GB одновременно? Что редкоиспользуемый стуфф будет неизбежно вытеснен на диск, и именно с диска поедет к клиенту?
К чему все эти рассуждения об умирании под нагрузкой? Я намекаю на то, что опытные товарщи из 1&1, к примеру, десять лет как отказались от хранения зон и состояния апача в текстовых конфигах. По тем самым причинам, которые я тут выписываю. А то, что RU-CENTER имеет наглость обновлять изменения зон с задержкой в 6 часов — так это они не от хорошей жизни. Большинство реальных пользователей как-то ожидают, что включение postini на их почтовом хостинге можно будет протестировать более-менее сразу, а не через день. И всё такое прочее.

S>> В частности, приличные СУБД точно так же кэшируют данные в памяти, как и любой самописаный config-based демон; в итоге путь запроса внутри машины не проходит через диск — всего лишь пара перемещений данных в памяти

AB>Т.е. на диск СУБД новые данные сбрасывать не обязана?! И инвалидировать кэши при изменении данных...
Давайте сопоставим частоты запросов на изменение зоны и на резолвинг записи. Сброс данных на диск делается лениво. Инвалидирование кэшей — вообще "бесплатная" операция, потому что любой update изначально делается с кэшем. И только потом из кэша данные сбрасываются на диск.
Я предлагаю не пытаться научить меня архитектуре СУБД. Я как бы в курсе того, как там внутри и снаружи всё устроено.

>> , а то и вовсе без перемещений, если драйвер доступа к СУБД умеет пользоваться shared memory. Зато СУБД умеет делать такие вещи, как точечные изменения без перезапуска нахрен всего

AB>А и не надо перезапускать все — достаточно перечитать и распарсить файл измененной зоны размером в 700 байт.
Очень хорошо. Но тем не менее, вся эта хня хорошо работает только в тепличных условиях. Для условий сервера с не-ручным управлением (а миллион доменов никто вручную не менеджит), текстовые конфиги подходят не очень хорошо. Что подтверждается практикой ведущих хостеров.

AB>OMG...
А что OMG? Мне вот не нравится ситуация, когда во время внесения изменений в файл зоны сбрасывается питание, или пропадает коннект между DNS-нодой и management-нодой, и bind остаётся в непонятном состоянии. С этой точки зрения ACID — очень удобно.

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

S> По-прежнему не понимаю этой сложной фразы. Можно для тупых расшифровать, где тут "удобно", и где "правильно"?

Хранить исходные данные ты можешь в любом "правильном" для тебя формате (каждый строчит как он хочет) — будь то СУБД, XML, текст и т.д. — DNS серверу (здесь и далее подразумевается bind как каноническое решение) это фиолетово — он загружает данные во внутреннее представление через промежуточный текстовый формат и далее работает сам по себе.

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

S> AB>О том, что при запуске данные зон читаются в память и живут в ней, пока не придет команда перечитать зону(ы).
S> Это тоже весьма спорная реализация.

Она эффективна с точки зрения скорости работы в типичных use-caseах. Есть альтернативное мнение? Готов выслушать.

S> AB>Откуда цифра?
S> С потолка, завышена.

Данные с потолка меня интересуют мало.

S> AB>Не, давай по другому. Представим себе сервер, обслуживающий всю зону RU. Вопросы:
...
S> AB>Ответив на эти вопросы ты получишь ответ на свой вопрос.
S> Ну, так если все ответы уже есть, то в чём прикол?

В том, что цифры, когда они берутся не с потолка, наглядно показывают полное безразличие сервера к исходному формату хранения данных.

S> То есть кому-то здесь непонятно, что современная ОС не даст тебе гарантию наличия в физической памяти всех 2.2 GB одновременно? Что редкоиспользуемый стуфф будет неизбежно вытеснен на диск, и именно с диска поедет к клиенту?

Вот ты вроде взрослый умный человек, а включил сейчас "дурочку". И нашел еще перед кем.

S> К чему все эти рассуждения об умирании под нагрузкой? Я намекаю на то, что опытные товарщи из 1&1, к примеру, десять лет как отказались от хранения зон и состояния апача в текстовых конфигах. По тем самым причинам, которые я тут выписываю.

Apache точно так же читает настройки в память. А где ты их хранишь в исходниках — да хоть на перфокартах.

S> А то, что RU-CENTER имеет наглость обновлять изменения зон с задержкой в 6 часов — так это они не от хорошей жизни. Большинство реальных пользователей как-то ожидают, что включение postini на их почтовом хостинге можно будет протестировать более-менее сразу, а не через день. И всё такое прочее.

А я думаю, что наоборот. Поскольку RU-CENTER хранит в большинстве своем информацию о делегировании, то перегружать информацию чаще просто не имеет смысла — как редко она меняется. Наложим еще на это TTL в кэшах и все станет на свои места.

S> Я предлагаю не пытаться научить меня архитектуре СУБД. Я как бы в курсе того, как там внутри и снаружи всё устроено.

Прекращай строить из себя обиженного ребенка. Ты прекрасно понимаешь, что прямой доступ к памяти быстрее, нежели почти тоже самое через прокладку СУБД (особенно, если это СУБД общего назначения) как бы она хорошо не работала. А когда мы начнем говорить о малом количестве зон на типичных дедиках, то поднимать ради этого СУБД будет просто непозволительной роскошью.

S> Очень хорошо. Но тем не менее, вся эта хня хорошо работает только в тепличных условиях. Для условий сервера с не-ручным управлением (а миллион доменов никто вручную не менеджит), текстовые конфиги подходят не очень хорошо. Что подтверждается практикой ведущих хостеров.

"Эта хня" работает в реальной жизни. Хорошо работает. Текстовые конфиги не обязывают к ручному управлению, что доказывают нам различные панели управления. Словосочетание "подтверждается практикой ведущих хостеров" равносильно "из достоверных источников".

S> А что OMG? Мне вот не нравится ситуация, когда во время внесения изменений в файл зоны сбрасывается питание, или пропадает коннект между DNS-нодой и management-нодой, и bind остаётся в непонятном состоянии. С этой точки зрения ACID — очень удобно.

Давай обсуждать более реалистичные сценарии, нежели отсутствие бэкапов и резервных вводов питания?

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

A>во-во. что я и сказал сообщением ранее да мне пофиг кто куда что ставит

Слив засчитан.

A> — 2к3 там отлично работал (и работает до сих пор). А может я дрова пишу? Мне таки что — покупать сервер?

2к3 ты уже купил?

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

AB>Хранить исходные данные ты можешь в любом "правильном" для тебя формате (каждый строчит как он хочет) — будь то СУБД, XML, текст и т.д. — DNS серверу (здесь и далее подразумевается bind как каноническое решение) это фиолетово — он загружает данные во внутреннее представление через промежуточный текстовый формат и далее работает сам по себе.

AB>Текстовый формат удобен тем, что прост в отладке, управлении, хранении как человеком, так и программно и, как было показано ранее, абсолютно не влияет на конечную производительность.
Про удобство — согласен на 100%. А вот про производительность — расскажи это парням из 1&1. Я не знаю, с чем связана твоя убеждённость, но текстовые конфиги имеют ограничения на предел масштабирования. Увы.

AB>Она эффективна с точки зрения скорости работы в типичных use-caseах. Есть альтернативное мнение? Готов выслушать.
Есть. Я уже трижды намекнул тебе, что 1&1 используют сильно допиленный DNS-сервер (не bind) и сильно допиленный Апач. Основной допил — отрезание нахрен текстовых конфигов.

AB>Данные с потолка меня интересуют мало.
Извини, реальные данные закрыты NDA.

AB>В том, что цифры, когда они берутся не с потолка, наглядно показывают полное безразличие сервера к исходному формату хранения данных.
А можно мне тогда попросить, чтобы RU-CENTER обновлял зоны не через 6 часов, а хотя бы через 10 минут, как делаем мы?

AB>Apache точно так же читает настройки в память. А где ты их хранишь в исходниках — да хоть на перфокартах.
Штатный апач — да. А вот если хочется получить реальную hi-density, то никаких перфоркарт и текстовых конфигов там не будет. И никакого "чтения настроек в память" — тоже не будет. Все настройки будут обрабатываться on demand. Точно так же, как и везде — приехал запрос, начинаем запрашивать "модуль конфигурации".

AB>А я думаю, что наоборот. Поскольку RU-CENTER хранит в большинстве своем информацию о делегировании, то перегружать информацию чаще просто не имеет смысла — как редко она меняется. Наложим еще на это TTL в кэшах и все станет на свои места.
Ну значит RU-CENTER — плохой пример. Я лично сталкиваюсь не с корневыми серверами, а с теми самыми, кому делегируют зоны. И вот там всё гораздо интереснее.

AB>Прекращай строить из себя обиженного ребенка. Ты прекрасно понимаешь, что прямой доступ к памяти быстрее, нежели почти тоже самое через прокладку СУБД (особенно, если это СУБД общего назначения) как бы она хорошо не работала. А когда мы начнем говорить о малом количестве зон на типичных дедиках, то поднимать ради этого СУБД будет просто непозволительной роскошью.
О! Достаточно перестать говорить о малом количестве зон, как все рассуждения о прелестях текстового конфига теряют актуальность.
Моя позиция именно потому и нетипична, что я говорю с учётом опыта работы с серверами массового обслуживания. Я прекрасно понимаю, что типичный корпоративный DNS сервер хостит две-три зоны, и текстовый конфиг в его случае не шоу-стоппер. Вот только народ всё больше уходит от "типичного корпоративного DNS-сервера", предпочитая хоститься в облаке.
А в облаке никто в здравом уме не будет выделять dedicated server на три зоны. Дадут мааахонький кусочек от мегакластера, где хостятся еще два-три миллиона зон. И там не будет никаких текстовых конфигов.

AB>"Эта хня" работает в реальной жизни. Хорошо работает. Текстовые конфиги не обязывают к ручному управлению, что доказывают нам различные панели управления.
Я, наверное, тебя разочарую. Я работаю как раз там, где производят эти "различные панели управления".
AB> Словосочетание "подтверждается практикой ведущих хостеров" равносильно "из достоверных источников".
Ну ты же не ожидал, что я тебе выложу интимные подробности бизнеса наших партнёров? Я NDA подписывал. Sapienti sat. Или ты предполагаешь, что я тут всё это из головы нафантазировал? Увы, нет.

AB>Давай обсуждать более реалистичные сценарии, нежели отсутствие бэкапов и резервных вводов питания?
Каких ещё бэкапов?
1. Чувак, пропадание питания в датацентре — это суровая реальность наших американских партнёров. Не надо мне тут рассказывать про дизели и всё такое — я имею информацию из первых рук.
2. Ну вот, допустим, у тебя навернулся твой bind с 2.2 GB данных зон. Сколько времени будет восстанавливаться "бэкап"?
3. Ок, ну вот ты сделал резервный сервер, который стоит в другом датацентре. Теперь у тебя узкое место — сеть. Начал ты писать через континент файлик зоны, тут в середине какая-то хня произошла — что будет? Наверное, это нифига не реалистичный сценарий. Тем не менее, я уже несколько раз наступал на то, что bind теряет зоны. Ну, конечно же, это лечится перегенерацией и рестартом, но раздражает очень сильно. Я бы предпочёл ACID, в котором ничего не пропадает.

Приветствую, Sinclair, вы писали:

S> О! Достаточно перестать говорить о малом количестве зон, как все рассуждения о прелестях текстового конфига теряют актуальность.
как я понял говорится не о малом количестве зон, а о том, что БД там наклеп не нужна.

S> Я, наверное, тебя разочарую. Я работаю как раз там, где производят эти "различные панели управления".
Оооооо, ну да, ну да, как мы могли забыть.
Теперь понятна твоя заинтересованность в том чтобы конфиги лежали в xml, а лучше всего вообще в БД.
Так и говори, что "мне было бы удобнее", а не "текстовые конфиги — нехорошо"