Re: ng_ipacct
- From
- Dmitry Pryanishnikov (2:464/36)
- To
- Eugene Grosbein
- Date
- 2006-12-21T22:45:34Z
- Area
- RU.UNIX.BSD
From: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>
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)
я написал неспроста. В этом разница наших подходов: Вы делаете некое общее
утверждение, я доказываю, что оно хорошо вовсе не для всех.
> Но ведь нельзя от каждого админа требовать такого понимания.
> Поэтому - следовать процедуре в UPDATING. Ну за исключением 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 САМЫМ КРУПНЫМ ШРИФТОМ) гораздо чаще
> dadu>> обновляю исходники базовой ОС и пересобираю именно ее, чем порты
> dadu>> (disclamer: речь идет о домашних и тестовых машинах, НЕ о 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)
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