Re: ng_ipacct

From

Dmitry Pryanishnikov (2:464/36)

To

Eugene Grosbein

Date

2006-12-22T15:00:58Z

Area

RU.UNIX.BSD

From: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>


Привет!

On Fri, 22 Dec 2006, Eugene Grosbein wrote:
> dadu>    А я и не спорю с необходимостью следования общей процедуре _в общем
> dadu> случае_. Однако так же, как Вас не волнуют "детали творческого процесса
> dadu> девелоперов", так же и меня не волнует Ваш оверхед.
>
> Если бы это был только мой оверхед, проблемы бы не было.

   Я согласен заплатить некоторым удлинением процесса компиляции за гарантию
соответствия разных "кирпичиков", из которых состоит ядро. Модуль гораздо
теснее интегрирован в ядро, чем любой userland-код, последствия 
рассинхронизации слишком опасны, чтобы допускать ее ради экономии времени.
Конечно, это мое IMHO, но вполне обоснованное.

> Кстати, я тебя чем-то обидел, что ты мне выкаешь? :-)

   В жизни и в Интернет "Вы" подчеркивает уважение к собеседнику. Я понимаю,
что большАя часть подписчиков конференции получает ее через FIDO (где другие
стандарты), но надеюсь на Ваше понимание - ведь многие пишут сюда из инета,
постоянно менять ты/Вы IMHO не есть разумно ;)

> dadu> Я не зря выделил Ваше слово _всем_. И IMHO (In My Humble/Honest Opinion)
> dadu> я написал неспроста. В этом разница наших подходов: Вы делаете некое
> dadu> общее
> dadu> утверждение, я доказываю, что оно хорошо вовсе не для всех.
>
> Ну девелоперам-то мои рекомендации точно не нужны,
> это само собой разумеется и не требует отдельного упоминания :-))

   Границы "девелопер-админ-пользователь" весьма размыты. Я вот в сетевых 
технологиях - админ, если нахожу проблему в ОС - часто сам предлагаю патч (в 
PR или просто в списке рассылки, если он тривиален), и потом его коммитят =>
участвую в девелопменте, а как дело доходит до какой-нибудь мультимедии -
ну чисто юзер ;) Поэтому, думаю, мои аргументы будут понятны не только
чистым девелоперам.

> >> Кроме diff-ов с технической точки зрения что-то ничего не видно;
> >> вычитывание листа cvs-src не может быть техническим методом обеспечения
> >> синхронности :-)
> dadu>    Неа, техническая сторона - это не вычитывание диффов, это обоснование
> dadu> границ между kernel, modules и userland в самом начале моего письма. Вот
> dadu> то же
> dadu> другими словами:
> dadu>> Ядро и модуля
> dadu>> из базовой системы, будучи загружены, работают по одну сторону высокой
> dadu>> и
> dadu>> мощной стены, разделяющей kernel land и user land. Остальной мир - по
> dadu>> другую.
> dadu>> Эта стена узаконена аппаратно (на i386 - supervisor vs user mode), и на
> dadu>> "КПП" через нее (сисколлах) сравнительно редко что-то меняется.
>
> Хм, это немножко далековато от технических методов обеспечения
> синхронности.

   Это технический метод локализации последствий рассинхронизации.

> Eugene

Sincerely, Dmitry
-- 
Atlantis ISP, System Administrator
e-mail:  dmitry@atlantis.dp.ua
nic-hdl: LYNX-RIPE
--- ifmail v.2.14.os-p7
 * Origin: Atlantis ISP (2:464/36@fidonet)
SEEN-BY: 46/999 50/12 400/814 450/1024 463/68 464/0 36 66 100 128 999 465/213
SEEN-BY: 550/5068 5000/0 20 26 27 61 94 104 116 130 170 5000 5002/76 5002
SEEN-BY: 5004/75 1111 5005/14 5009/14 5010/77 275 5011/13 5012/46 5013/21
SEEN-BY: 5015/28 5019/26 5020/400 545 2238 2395 2871 4441 5021/29 5025/3
SEEN-BY: 5027/12 5029/34 5030/1080 1957 5035/38 5045/7 5054/1 4 8 9 11 28 35
SEEN-BY: 5054/36 37 45 66 67 70 75 84 85 5055/177 5057/119 5059/9 5062/10
SEEN-BY: 5063/3 5064/7 5070/66 5076/1 5077/70 5084/9 5085/13 5090/1029 5095/20
SEEN-BY: 5096/18 6001/10 6090/1

PATH: 464/36 5000/5000 5020/545 5054/1 37