|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Dmitry Pryanishnikov 2:464/36 22 Dec 2006 16:00:58
To : Eugene Grosbein
Subject : Re: ng_ipacct
--------------------------------------------------------------------------------
Привет!
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> утверждение, я доказываю, что оно хорошо вовсе не для всех.
>
> Hу девелоперам-то мои рекомендации точно не нужны,
> это само собой разумеется и не требует отдельного упоминания :-))
Границы "девелопер-админ-пользователь" весьма размыты. Я вот в сетевых
технологиях - админ, если нахожу проблему в ОС - часто сам предлагаю патч (в
PR или просто в списке рассылки, если он тривиален), и потом его коммитят =>
участвую в девелопменте, а как дело доходит до какой-нибудь мультимедии -
ну чисто юзер ;) Поэтому, думаю, мои аргументы будут понятны не только
чистым девелоперам.
> >> Кроме diff-ов с технической точки зрения что-то ничего не видно;
> >> вычитывание листа cvs-src не может быть техническим методом обеспечения
> >> синхронности :-)
> dadu> Hеа, техническая сторона - это не вычитывание диффов, это обоснование
> 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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
