/var/db/freebsd-update

Slawa Olhovchenkov написал(а) к Alex Korchmar в May 18 21:40:16 по местному времени:

Нello Alex!

07 May 18, Alex Korchmar writes to Slawa Olhovchenkov:

AK>>>>> ну а как бы ты это делал с svn?
SO>>>> делал что? разделение нескольких веток и их одновременная
SO>>>> поддержка
AK>>> ну да, ну да. Оно же другим способом не умеет ;-)
SO>> ты не изображай таинственное лицо, ты пальцем покажи.
AK> ну я говорю - не умеет этого svn, не для того придуман.

пальцем покажи

SO>> и чё? у меня никогда не было и не планировалось отдельными
SO>> наборами независимые части.
AK> для тебя на твоем локалхосте это будут просто последовательные комиты.
AK> патчи из них делаются специально для экспорта, а не история хранится в виде
AK> патчей к патчам, как нам продемонстрировал Женя.

и нахуй мне это? это будет абсолютно бесполезно.

SO>> беда! но гит тут не причем.
AK> причем. У тебя нет никакой возможности другим способом нормально вести
AK> работу с проектом, где апстрим - не ты.

это твоя фантазия. у меня сейчас нет апстрима.
а для обновления патча нужно что бы он появился. а его не предусматривалось.
то, что ты хочешь за апстрим -- я игнорировал. у меня нет апстрима сейчас.

SO>> а это другая проблема -- то, что на review надо патч целиком грузить,
SO>> ванильный, поправить руками его нельзя.
SO>> впрочем с гитом была бы та же самая проблема -- развернуть ванильные
SO>> сырцы,
AK> с гитом тебе не надо править патч руками, он его тебе сам соберет из
AK> помеченных кусков. Проверять на собираемость, причем, можно прямо в своем
AK> дереве, а потом вернуть как было, включая еще недосохраненные правки.

тьфу. ты опять ничего не понял.

... Возвpащается муж внезапно домой из Интеpнета...
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Slawa Olhovchenkov в May 18 22:31:14 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

AK>> ну я говорю - не умеет этого svn, не для того придуман.
SO> пальцем покажи
что? Чего в нем НЕТ ?

SO> это твоя фантазия. у меня сейчас нет апстрима.
ты патчи пилишь под freebsd, или под свою ос написанную под твоим контролем?
Это вот называется апстрим.
Пока он твой - можно обойтись централизованной vcs, хотя и неудобно (потому
что либо твои огрехи и ляпы видны всему миру, либо ты рискуешь что-то забыть)
а как чужой - так приехали, живем без vcs вообще, по сути. "новая папка(32)"

SO> а для обновления патча нужно что бы он появился.
для обновления патча нужно иметь что обновлять. А сборную солянку обновлять
невозможно, ее надо сперва обратно разбирать.


> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в May 18 04:42:18 по местному времени:

07 мая 2018, понедельник, в 16:19 NOVT, Alex Korchmar написал(а):

AK>>> у меня freebsd, видимо, навсегда уже ограничена в применении виртуалками,
EG>> А тогда тебе тем более не надо ничего выкорчевывать.
AK> оно a) опасное

А что у нас не опасное?

b) ненужное

Тебе.

c) лишние тормоза на лишних проверках

Отключено по дефолту. И ты не тестировал в своих условиях, правда?

Фишка в том, что такого кода там, не менее
"опасного, ненужного и добавляющего тормозов" - тонны!

Но ты почему-то возбудился на выпиливание именно этой фичи,
хотя там полным-полно других, гораздо более инвазивных
типа пропитавшей всё и вся поддержки jail. Внезапно
даже ядро без опции VIMAGE содержит в себе код,
поддерживающий защищённый мутексом unsigned long hostid,
разный для разных jail и нулевой для хоста и сетевой код
разных подсистем периодически может лочится на мутексе,
читая этот hostid. И т.д. и т.п.

EG>> Ничего из того, что нужно тебе. Внезапно, другим нужно другое.
AK> скорее всего окажется, что это другое гораздо лучше, быстрее и эффективнее
AK> делают другие системы, а "другие" либо упертые фанатики, которым похрен на
AK> эффективность, либо продолжают барахтаться по инерции.
AK> Сколько-сколько проектов за последние десять лет избавились от freebsd?

NetFlix тем временем был занят оптимизированием узких мест
сетевого кода ядра (узкие места есть всегда по определению)
и добился выдачи 90 гигабит в секунду шифрованного TLS-ом
трафика TCP большим количеством потоков и одной сетевой
100-гигабитной картой PCI-E 3.

Так что это нормально, когда кто-то избавляется от freebsd.
Кто-то при этом избавляется от Windows, и т.д.

EG>> Я всё ещё не понимаю, зачем что-то "вытаскивать", оно в виде патчей
EG>> так ведь и хранится всегда и при обновлении системы патчи применяются
EG>> каждый раз на обновленные чистые исходники.
AK> по одному. вручную. С риском что они пересекутся и не приложатся правильно.
AK> Понятно. Скажи, а зачем вам вообще svn?

Если ты не в курсе, то SVN для FreeBSD это не средство разработки кода,
официально. Это средство публикации кода и хранения истории.

А разработка может вестись разработчиком или группой разработчиков
где им угодно - в perforce, в git, да хоть в RCS. На эту тему
ещё в эпоху CVS как-то был небольшой конфликт с участием,
ЕМНИП, кого-то из зубров (может быть даже покойного ache@),
вызванный непониманием этого момента, когда кто-то пытался
именно что девелопить в общем репозитории, ломая CURRENT,
а не выкладывая туда готовые обновы.

EG>> find $d/system -type f -name '*.diff' | sort | xargs cat |\
EG>> patch /var/log/pw.log 2>&1
AK> и что делать если он a) сфейлился b) пропатчил неправильно ?

Нет никакой разницы с другими инструментами - чинить.

AK> и не вижу еще одного куска мэйкфайла - который все-все патчи
AK> переделывает заново (и смотри не перепутай, какой где) - после решения этих
AK> проблем,

А оно не нужно. Достаточно запустить в нужном подкаталоге
svn diff > конкретный.diff для конкретного файла после внесения правок.
Ты думаешь, xargs cat там просто так? :-)

Eugene
--- slrn/1.0.2 (FreeBSD)

Alex Korchmar написал(а) к Eugene Grosbein в May 18 00:48:48 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

AK>> оно a) опасное
EG> А что у нас не опасное?
отсутствие ненужнопатча - не опасно.
EG> b) ненужное
EG> Тебе.
никому. Поскольку никакой проблемы не решает.

EG> c) лишние тормоза на лишних проверках
EG> Отключено по дефолту. И ты не тестировал в своих условиях, правда?
проверка "а не включено ли, чисто случайно" в очень критичной секции,
вызываемой при всяком контекст-свитче, конечно же, совершенно не влияет
на производительность?
Но я не тестировал, да, выкинул по пункту а.

EG> Фишка в том, что такого кода там, не менее
EG> "опасного, ненужного и добавляющего тормозов" - тонны!
тонны. Но про него я не в курсе, и не знаю как выпилить.
EG> Но ты почему-то возбудился на выпиливание именно этой фичи,
потому что от нее сравнительно легко было отделаться. Из current уже
не выпилить.

EG> хотя там полным-полно других, гораздо более инвазивных
EG> типа пропитавшей всё и вся поддержки jail. Внезапно
если бы я знал, как вернуть обратно jail времен 4 - я бы, безусловно, это
сделал.

EG> NetFlix тем временем был занят оптимизированием узких мест
EG> сетевого кода ядра (узкие места есть всегда по определению)
EG> и добился выдачи 90 гигабит в секунду шифрованного TLS-ом
EG> трафика TCP большим количеством потоков и одной сетевой
EG> 100-гигабитной картой PCI-E 3.
на своем специфическом кейсе, существующем в одном-единственном месте.
Не факт что для простых смертных при этом что-нибудь не испортили.
Кстати, в линуксе есть уже аж два стека, dpdk и имени BBC, вообще игнорирующие
ядро и его сетевой код (для выплевывания udp потока без контроля доставки,
в общем-то, нафиг не нужен). Производительность примерно та же.

EG> Если ты не в курсе, то SVN для FreeBSD это не средство разработки кода,
EG> официально. Это средство публикации кода и хранения истории.
а зачем ее хранить в svn? Новая папка(123) (ну или как в линуксе принято было
первые восемь лет - linux-0.99.3.tar.gz patch-0.99.4.gz patch-0.99.5.gz
кстати, лучше сжимается)

EG> А разработка может вестись разработчиком или группой разработчиков
EG> где им угодно - в perforce, в git, да хоть в RCS. На эту тему
только вот когда нельзя сделать fetch - это не работа с git, а унылая $@ля.
Впрочем,возможно таки git-svn тут чем-то и поможет, но забавно, что тут
никто даже не в курсе, зачем оно так нужно.

Повторю: в линуксе так было в 98м году. Кто-то вынужден был вручную каждый
раз синхронизировать свое дерево с общим, чтобы сохранить хотя бы возможность
использовать собственные версии и обмениваться ими внутри своей команды
(но без всякой связи с общим проектом и, разумеется, без его собственной
истории, merge 0.99.3 merge 0.99.4 и т д.)
К счастью, всего за четыре года, Линуса удалось убедить, хотя и пришлось
очень сильно изуродовать инструмент ради его личных тараканов.

EG> именно что девелопить в общем репозитории, ломая CURRENT,
EG> а не выкладывая туда готовые обновы.
git и эту проблему решает - там не принято (и невозможно при типичных
сетапах) ничего "выкладывать". Выкладываются патчи для ревью. Всасываются
(при помощи стандартных инструментов) автоматом.
EG>>> find $d/system -type f -name '*.diff' | sort | xargs cat |\
EG>>> patch /var/log/pw.log 2>&1
AK>> и что делать если он a) сфейлился b) пропатчил неправильно ?
EG> Нет никакой разницы с другими инструментами - чинить.
"другой инструмент" останавливается на проблемном файле, и спрашивает что
ему делать, а не требует рытья по логу на энцать страниц, с риском вообще
пропустить проблему.

EG> А оно не нужно. Достаточно запустить в нужном подкаталоге
EG> svn diff > конкретный.diff для конкретного файла после внесения правок.
вручную?
широко жил партизан Боснюк...

> Alex

--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Alex Korchmar в May 18 19:42:38 по местному времени:

07 мая 2018, понедельник, в 22:48 NOVT, Alex Korchmar написал(а):

AK>>> оно a) опасное
EG>> А что у нас не опасное?
AK> отсутствие ненужнопатча - не опасно.
EG>> b) ненужное
EG>> Тебе.
AK> никому. Поскольку никакой проблемы не решает.

Ты как всегда абсолютизируешь свои привычки. Не решает только
в твоих условиях - а я вот нынче занимаюсь PR'ом человека с FreeBSD
на ноутбуке, автоматизируя повторное вливание обновленного микрокода
CPU после просыпания системы. Собственно, сам код там элементарная
добавка в /etc/rc.resume (вызов rcorder -k resume) и он уже работает,
осталось только документацию обновить. А майские обновления микрокодов
от Intel добавляют поддержку IBRS, которую использует код,
который ты упорно пытаешься выпилить.

AK> Но я не тестировал, да, выкинул по пункту а.

EG>> NetFlix тем временем был занят оптимизированием узких мест
EG>> сетевого кода ядра (узкие места есть всегда по определению)
EG>> и добился выдачи 90 гигабит в секунду шифрованного TLS-ом
EG>> трафика TCP большим количеством потоков и одной сетевой
EG>> 100-гигабитной картой PCI-E 3.
AK> на своем специфическом кейсе, существующем в одном-единственном месте.
AK> Не факт что для простых смертных при этом что-нибудь не испортили.
AK> Кстати, в линуксе есть уже аж два стека, dpdk и имени BBC, вообще игнорирующие
AK> ядро и его сетевой код (для выплевывания udp потока без контроля доставки,
AK> в общем-то, нафиг не нужен). Производительность примерно та же.

Только dpdk и netmap это вовсе не "стек", это как раз таки фреймворк
для девелоперов, чтобы писать свои приложения в обход какого-либо
универсального стека, затачивая весьма конкретные чипы под решения
узкоспециальных задач. Тоже себе подход, но требует серьезного
программирования на фреймворке, вместо портабельных API типа
BSD sockets или там POSIX.

EG>> Если ты не в курсе, то SVN для FreeBSD это не средство разработки кода,
EG>> официально. Это средство публикации кода и хранения истории.
AK> а зачем ее хранить в svn?

Для истории и коммит-логов. Ну ещё merge из head в stable чуть проще.

AK> Повторю: в линуксе так было в 98м году.

И опять ты зачем-то тянешь в обсуждение линукс, несмотря на то,
что там вовсе не "так".

AK>>> и что делать если он a) сфейлился b) пропатчил неправильно ?
EG>> Нет никакой разницы с другими инструментами - чинить.
AK> "другой инструмент" останавливается на проблемном файле, и спрашивает что
AK> ему делать, а не требует рытья по логу на энцать страниц, с риском вообще
AK> пропустить проблему.

patch возвращает ненулевой код ошибки и сборка даже не начнется,
если что-то не наложилось. И рыться глазками по логу не надо - если
patch вылетел с ошибкой, то и в логе, и на файловой системе будут
.rej-файлы.

EG>> А оно не нужно. Достаточно запустить в нужном подкаталоге
EG>> svn diff > конкретный.diff для конкретного файла после внесения правок.
AK> вручную?
AK> широко жил партизан Боснюк...

Можно подумать, git-команды ты запускаешь ментальным управлением,
а не точно так же вручную.

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.2 (FreeBSD)

Eugene Grosbein написал(а) к All в May 18 19:44:30 по местному времени:

08 мая 2018, вторник, в 18:42 NOVT, Eugene Grosbein написал(а):

EG> осталось только документацию обновить. А майские обновления микрокодов
EG> от Intel добавляют поддержку IBRS, которую использует код,
EG> который ты упорно пытаешься выпилить.

s/майские/мартовские/

Речь про microcode-20180312.tgz

Eugene
--- slrn/1.0.2 (FreeBSD)

Alex Korchmar написал(а) к Eugene Grosbein в May 18 18:11:16 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

EG> Ты как всегда абсолютизируешь свои привычки. Не решает только
EG> в твоих условиях - а я вот нынче занимаюсь PR'ом человека с FreeBSD
ни в каких. Это костыль. Затыкает один-единственный вариант атаки.
Из миллиона возможных. Вот конкретно сейчас zero и еще какие-то гаврики
придумали еще пяток вариантов. Интел уже обещал обновление к этому обновлению,
а обезьянкам уже накручены хвосты и они уже ляпают очередные кривые и
толком не тестированные исправления в ядра.

Опять затыкающие один конкретный способ угадава содержимого чужой памяти,
хватит ровно до завтра, когда кто-нибудь придумает еще один, и так до
бесконечности. Потому что проблема архитектурная, и заткнуть ее невозможно.

EG> Только dpdk и netmap это вовсе не "стек", это как раз таки фреймворк
EG> для девелоперов, чтобы писать свои приложения в обход какого-либо
EG> универсального стека, затачивая весьма конкретные чипы под решения
потому что он не нужен для задачи "плюнуть односторонний поток udp-хлама".
А если ты попытаешься использовать улучшенный нетфликсом стек для чего-то
другого, никаких 90G там и близко не получится в любом случае.

EG> узкоспециальных задач. Тоже себе подход, но требует серьезного
EG> программирования на фреймворке, вместо портабельных API типа
EG> BSD sockets или там POSIX.
при таких потоках это проще, чем копаться с сокетами. Потому что еще один ком
проблем тут в самом приложении, которое должно стабильно нагружать
отдачу, не забывая с этим же диким рейтом успевать добывать данные с источника.
Это проще делать, когда у тебя есть прямой контроль над состоянием
буферов на отправку.

EG> И опять ты зачем-то тянешь в обсуждение линукс, несмотря на то,
EG> что там вовсе не "так".
я говорю о том, что при всей дубоголовости его идеологов, они все же за четыре
года осилили научиться новому (там у учителя был конкретный шкурный
интерес, но его хотя бы стали слушать). А беэесде и ныне живет в XX веке, хотя
cvs научились пользоваться за десять лет до них. Но так там и застряли.

EG> patch возвращает ненулевой код ошибки и сборка даже не начнется,
EG> если что-то не наложилось. И рыться глазками по логу не надо - если
угу, будем искать rej find'ом, вот удобство-то...

EG>>> svn diff > конкретный.diff для конкретного файла после внесения правок.
AK>> вручную?
AK>> широко жил партизан Боснюк...
EG> Можно подумать, git-команды ты запускаешь ментальным управлением,
гит-команды не требуют вручную собирать конкретный дифф для конкретного
файла, и так сто раз. И ручным поиском по всему дереву реджектов тоже не
страдают.

> Alex

--- ifmail v.2.15dev5.4

Slawa Olhovchenkov написал(а) к Alex Korchmar в May 18 19:30:50 по местному времени:

Нello Alex!

07 May 18, Alex Korchmar writes to Slawa Olhovchenkov:

AK>>> ну я говорю - не умеет этого svn, не для того придуман.
SO>> пальцем покажи
AK> что? Чего в нем НЕТ ?

вот и покажи пальцем, чего там нет.
а то пока только умное лицо строишь.
вот по простому, типа делай раз-два-три, получаешь тык-пык-мык.
пока все твои примеры один-в-один реализовывались в svn, при том же самом условии, что и с git: заранее подумать об разделении и постоянно его поддерживать.

SO>> это твоя фантазия. у меня сейчас нет апстрима.
AK> ты патчи пилишь под freebsd, или под свою ос написанную под твоим
AK> контролем?

по факту скорее не под freebsd, раз как раз на пиленное место у меня наложен UMA патч, который не мой и я не синхронизируюсь (по факту) со stable.

AK> Это вот называется апстрим. Пока он твой - можно обойтись
AK> централизованной vcs, хотя и неудобно (потому что либо твои огрехи и
AK> ляпы видны всему миру, либо ты рискуешь что-то забыть)

ты что-то не то несешь. у меня есть такая разработка и там спокойно все пилится.

AK> а как чужой - так приехали, живем без vcs вообще, по сути. "новая
AK> папка(32)"

и такая тоже есть, опять же никаких проблем.

SO>> а для обновления патча нужно что бы он появился.
AK> для обновления патча нужно иметь что обновлять. А сборную солянку обновлять
AK> невозможно, ее надо сперва обратно разбирать.

с гитом тоже самое.

... Функция хвоста pыбы - pулезная!
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Slawa Olhovchenkov в May 18 20:28:23 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:

AK>>>> ну я говорю - не умеет этого svn, не для того придуман.
SO>>> пальцем покажи
AK>> что? Чего в нем НЕТ ?
SO> вот и покажи пальцем, чего там нет.
возможности работы с чужим проектом - нет. Начисто.

SO> вот по простому, типа делай раз-два-три, получаешь тык-пык-мык.
SO> пока все твои примеры один-в-один реализовывались в svn, при том же самом
я не вижу как реализовать в svn, что с подпорками, что без, работу с
репо в который нельзя комитить, и из которого надо получать апдейты.

SO> условии, что и с git: заранее подумать об разделении и постоянно его
SO> поддерживать.
поддерживать надо атомарность изменений - поменял что-то конкретное -
commit. Как при работе с любой другой vcs, если она используется для разработки
а не для чего-то непонятного ("хранения истории непонятно чего"), как у
freebsd.

SO> по факту скорее не под freebsd, раз как раз на пиленное место
SO> у меня наложен UMA патч, который не мой и я не синхронизируюсь
dvcs все равно, твой он или нет (если, конечно, его автор тоже умеет
ей пользоваться), там нет обязанности делать fetch из одного источника.

SO> ты что-то не то несешь. у меня есть такая разработка и там спокойно все
SO> пилится.
я вот озвучил свою вполне реальную проблему - этих самых патчей у меня
уже вагон и маленькая тележка, у каждого своя отдельная история, а патчат они
все - не мой проект. Внезапно, выясняется что все кто с ним связан, вообще
про dvcs не слышали, работать с ними не умеют, кроме "новая папка" механизмов
не знают.

SO> с гитом тоже самое.
нет.

> Alex

--- ifmail v.2.15dev5.4

Slawa Olhovchenkov написал(а) к Alex Korchmar в May 18 20:40:32 по местному времени:

Нello Alex!

08 May 18, Alex Korchmar writes to Slawa Olhovchenkov:

AK>>>>> ну я говорю - не умеет этого svn, не для того придуман.
SO>>>> пальцем покажи
AK>>> что? Чего в нем НЕТ ?
SO>> вот и покажи пальцем, чего там нет.
AK> возможности работы с чужим проектом - нет. Начисто.

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

SO>> вот по простому, типа делай раз-два-три, получаешь тык-пык-мык.
SO>> пока все твои примеры один-в-один реализовывались в svn, при том же
SO>> самом
AK> я не вижу как реализовать в svn, что с подпорками, что без, работу с
AK> репо в который нельзя комитить, и из которого надо получать апдейты.

а в чем проблема?
если ты не делаешь svn ci то и пофиг на на коммиты.

SO>> условии, что и с git: заранее подумать об разделении и постоянно его
SO>> поддерживать.
AK> поддерживать надо атомарность изменений - поменял что-то конкретное -
AK> commit.

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

SO>> по факту скорее не под freebsd, раз как раз на пиленное место
SO>> у меня наложен UMA патч, который не мой и я не синхронизируюсь
AK> dvcs все равно, твой он или нет (если, конечно, его автор тоже умеет
AK> ей пользоваться), там нет обязанности делать fetch из одного источника.

да причем тут этот фетч?! ну нет в этом месте проблемы, насрать на это.

SO>> ты что-то не то несешь. у меня есть такая разработка и там спокойно
SO>> все пилится.
AK> я вот озвучил свою вполне реальную проблему - этих самых патчей у меня
AK> уже вагон и маленькая тележка, у каждого своя отдельная история, а патчат
AK> они все - не мой проект. Внезапно, выясняется что все кто с ним связан,
AK> вообще про dvcs не слышали, работать с ними не умеют, кроме "новая папка"
AK> механизмов не знают.

svk mirror svn://svn.freebsd.org/base/stable/11 //mirror/FreeBSD
svk sync //mirror/FreeBSD
svk cp -p //mirror/FreeBSD //FreeBSD/export
svk cp -p //FreeBSD/export //FreeBSD/patch1
svk cp -p //FreeBSD/export //FreeBSD/patch2
svk cp -p //FreeBSD/export //FreeBSD/patch3
svk smerge -l //FreeBSD/patch1 //FreeBSD/export
svk smerge -l //FreeBSD/patch2 //FreeBSD/export
svk smerge -l //FreeBSD/patch3 //FreeBSD/export

как-то так.

SO>> с гитом тоже самое.
AK> нет.

да.

... Наши баги мы для совместимости сохраним в следующих версиях
--- GoldED+/BSD 1.1.5-b20110223-b20110223