|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Dmitry Pryanishnikov 2:464/36 21 Dec 2006 23:45:35
To : Eugene Grosbein
Subject : Re: ng_ipacct
--------------------------------------------------------------------------------
On Fri, 22 Dec 2006, Eugene Grosbein wrote:
> dadu> из-за ее пределов. Потому по-умолчанию граница проведена именно по стыку
> dadu> 1 (между (kernel+modules) и userland), и это правильно.
>
> Кого волнуют детали творческого процесса девелоперов,
> когда дело касается рабочих систем, пусть это даже будет STABLE
> как девелоперская ветка? При обновлении исходников надо пересобирать
> и мир тоже, пересобирутся модули с ним или с ядром уже не важно.
> Изменения конфигурации ядра без изменений исходников не требуют
> оверхеда make modules и совершенно непонятно, зачем он нужен.
> При изменении исходников все равно пересобирать всю систему,
> и mergemaster тоже, да.
А я и не спорю с необходимостью следования общей процедуре _в общем
случае_. Однако так же, как Вас не волнуют "детали творческого процесса
девелоперов", так же и меня не волнует Ваш оверхед. Однако, поднимите
мое первое письмо по этой теме:
>> Все такие странные проблемы уходят, всем рекомендую.
>
> IMHO зря _всем_ рекомендуете.
Я не зря выделил Ваше слово _всем_. И IMHO (In My Humble/Honest Opinion)
я написал неспроста. В этом разница наших подходов: Вы делаете некое общее
утверждение, я доказываю, что оно хорошо вовсе не для всех.
> Hо ведь нельзя от каждого админа требовать такого понимания.
> Поэтому - следовать процедуре в UPDATING. Hу за исключением single useer
^^^^^^^^^^^^^^^^^^^^^^
Я надеюсь, здесь просто пропущены слова, а не повелительное наклонение?
> dadu> А с технической точки зрения - см. выше.
>
> Кроме diff-ов с технической точки зрения что-то ничего не видно;
> вычитывание листа cvs-src не может быть техническим методом обеспечения
> синхронности :-)
еа, техническая сторона - это не вычитывание диффов, это обоснование
границ между kernel, modules и userland в самом начале моего письма. Вот то же
другими словами:
> dadu> Ядро и модуля
> dadu> из базовой системы, будучи загружены, работают по одну сторону высокой и
> dadu> мощной стены, разделяющей kernel land и user land. Остальной мир - по
> dadu> другую.
> dadu> Эта стена узаконена аппаратно (на i386 - supervisor vs user mode), и на
> dadu> "КПП" через нее (сисколлах) сравнительно редко что-то меняется.
>
> Да не так уж редко. Если следовать принципу "работает - не трогай"
> и обновлять систему в среднем раз в релиз (плюс когда Security Advisory
> рекомендует), то пересобирать таки придется. А сильно чаще обновляться
> смысла просто нет для стабильно работающих релизов/снапшотов.
You've missed my disclamer:
>> (disclamer: речь идет о домашних и тестовых машинах,
Е о production).
> dadu>> Ту хум хау. Я как раз (я, IMHO САМЫМ КРУПHЫМ ШРИФТОМ) гораздо чаще
> dadu>> обновляю исходники базовой ОС и пересобираю именно ее, чем порты
> dadu>> (disclamer: речь идет о домашних и тестовых машинах, HЕ о production).
> >> И при этом мир не пересобираешь? Вот не надо бы такого озвучивать
> >> без варнингов.
> dadu> Каким шрифтом мне написать IMHO, чтобы Вы увидели?
>
> IMHO это ни разу ни варнинг.
Это подчеркивание частности подхода. Я не претендую на общность, я просто
показываю слабую сторону Вашего обощения.
> >> При переходе с 4 на 6 легко без этого обошелся на десктопе.
> >> User-threads никуда не делись, и libc_r.so от четверки тоже.
> dadu> А никто и не говорит, что работать не будет (для того и compatYx
> dadu> создают,
> 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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
