/var/db/freebsd-update

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

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

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

SO> впрочем ты опять не сказал, что именно нельзя сделать
ничего из того что делается в vcs - нельзя.

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

Ведь так прекрасна и удобна "новая папка(254)"

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

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

SO> уже и этого достаточно, а для полного кайфа они не разделяются по методу
SO> "публично только часть изменений".
значит будут две ветки с эпизодическим merge. Противно и неудобно (именно в
git это сделано плохо, хорошо в hg) но всяко лучше чем "новая папка(256)(копия)"

SO> самое. и если если я в логике
SO> делаю исправления, то править надо в двух местах.
merge, исправляем, commit, rebase.
Неудобно, но a) сохраняется история изменений в каждой ветке в отдельности
b) можно посмотреть чем отличаются ветки и вовремя заметить ошибку

но это у тебя какой-то особо запущенный случай, мне, во всяком случае для
freebsd, такого не надо, у меня нет нескольких разных кодов для разных случаев.
(в своих проектах есть, там есть stage который отличается от prod, это разные
ветки)

SO> svk mirror svn://svn.freebsd.org/base/stable/11 //mirror/FreeBSD
SO> svk sync //mirror/FreeBSD
SO> svk cp -p //mirror/FreeBSD //FreeBSD/export
не, это п-ц какой-то. 96й год на дворе. Во-первых, я работаю с файлами,
а не с патчами. У меня есть рабочее дерево исходников, и в идеале оно одно.
У исходников есть история, она нелинейна - есть история апстрима (апстримов),
есть мои правки поверх апстрима, есть правки моих правок из-за изменений в
апстриме, и еще я тут в корень просыпал гиг фото с котятками, хорошо бы это
вовремя заметить (нет, удалять не надо, у меня нет копии).
Все это (в виде, напомню, дерева развернутых исходников, а не отдельных патчей)
можно вытащить в любой момент на любое состояние, если текущая версия почему-то
кажется мне подозрительной, или я просто хочу посмотреть, как оно было, к
примеру, до kpti.

С патчами я вообще не работаю - что мне, патч редактировать, что-ли?

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

> Alex

--- ifmail v.2.15dev5.4

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

Нello Alex!

08 May 18, Alex Korchmar writes to Slawa Olhovchenkov:

SO>> впрочем ты опять не сказал, что именно нельзя сделать
AK> ничего из того что делается в vcs - нельзя.

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

AK> Ведь так прекрасна и удобна "новая папка(254)"

т.е. это предмет веры, ведь ни одного юзкейса ты привести не можешь.

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

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

ты вообще читаешь, что я пишу?
я же тоже самое пишу.
а дополнительно -- публично должно быть одно, а для меня другое.

SO>> уже и этого достаточно, а для полного кайфа они не разделяются по
SO>> методу "публично только часть изменений".
AK> значит будут две ветки с эпизодическим merge. Противно и неудобно (именно в
AK> git это сделано плохо, хорошо в hg) но всяко лучше чем "новая
AK> папка(256)(копия)"

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

SO>> самое. и если если я в логике
SO>> делаю исправления, то править надо в двух местах.
AK> merge, исправляем, commit, rebase.
AK> Неудобно, но a) сохраняется история изменений в каждой ветке в отдельности
AK> b) можно посмотреть чем отличаются ветки и вовремя заметить ошибку

нельзя. моей внимательности на это не хватит.

AK> но это у тебя какой-то особо запущенный случай,

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

SO>> svk mirror svn://svn.freebsd.org/base/stable/11 //mirror/FreeBSD
SO>> svk sync //mirror/FreeBSD
SO>> svk cp -p //mirror/FreeBSD //FreeBSD/export
AK> не, это п-ц какой-то. 96й год на дворе. Во-первых, я работаю с файлами,
AK> а не с патчами. У меня есть рабочее дерево исходников, и в идеале оно одно.

//FreeBSD/export -- это сумма.

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

все ок.

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

patchN -- это условное название проекта. пиши nokpti. там полное дерево, с историей и всем прочим.
или тебе места на диске тоже жалко?

... С вас бы за указание на четверть литра...
--- GoldED+/BSD 1.1.5-b20110223-b20110223

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

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

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

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

SO> а дополнительно -- публично должно быть одно, а для меня другое.
это две ветки. Плохо, но не фатально. Когда их именно две ветки, а не
двадцать два набора почти одинаковых патчей по "новым папкам".

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

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

SO> //FreeBSD/export -- это сумма.
у меня нет "суммы". У меня рабочее дерево, из которого я world здесь собираю.
Из его истории добываются частичные наборы патчей, для отдачи кому-то.
Эта штука, похоже, так не умеет, у нее только "ветки". То есть они решили одну
проблему - "как коммитить свои правки, не имея доступа к оригиналу", но не
весь комплекс.

SO> patchN -- это условное название проекта. пиши nokpti. там полное дерево, с
SO> историей и всем прочим.
SO> или тебе места на диске тоже жалко?
а зачем оно мне? Чтобы путаться, "чорт, не в том дереве поправил"? Дык, вот,
уже.
Я мир-то собираю только один. Ну может быть раз в год мне захочется
рядом развернуть второе дерево, с принципиально другой веткой, чтобы проверить,
что вообще еще собирается. Для этого делается clone, то есть дерево копируется
вместе с репо. Правки, если случатся, потом втянутся в основной.
Тестировать всяко буду на другой машине, или не буду вовсе (что типично для
отдаваемых вовне кусков, нехай те кому отдают тестят).


> Alex

--- ifmail v.2.15dev5.4

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

08 мая 2018, вторник, в 16:11 NOVT, Alex Korchmar написал(а):

AK> ни в каких. Это костыль. Затыкает один-единственный вариант атаки.

Ты говоришь так, будто фиксы против buffer overflow - каждого конкретного
в отдельности - тоже не нужны, ведь каждый их них затыкает один-единственный
вариант атаки, а весь класс проблем с buffer overflow они не решают.

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

Получится. Там ничего не сломано - есть пара сомнительных мест максимум,
но это лечится.

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

Да я ж не говорю, что подход не имеет права на жизнь, просто не надо
это называть "другим стеком", потому как стек протоколов TCP/IP это другое.
В dpkg и в netmap нет этого стека протоколов.

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

Незачем искать его find'ом, лог же есть.

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

Зато они требуют гораздо больше других вызовов и заточены под гораздо
более сложную модель разработки, которая мне solo не нужна.

Eugene
--
Научить не кланяться авторитетам, а исследовать их и сравнивать их поучения
с жизнью. Научить настороженно относиться к опыту бывалых людей, потому что
жизнь меняется необычайно быстро.
--- slrn/1.0.2 (FreeBSD)

Victor Sudakov написал(а) к Alex Korchmar в May 18 12:18:24 по местному времени:

Dear Alex,

08 May 18 22:09, Alex Korchmar wrote to Slawa Olhovchenkov:

[dd]

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

Это в git (а лучше в hg) какая команда делает (отдать только часть изменений)?

В качестве ликбеза, можешь не отвечать если лень.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

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

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

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

AK>> ни в каких. Это костыль. Затыкает один-единственный вариант атаки.
EG> Ты говоришь так, будто фиксы против buffer overflow - каждого конкретного
EG> в отдельности - тоже не нужны,
фиксы в ядре системы или уродованием компиляторов - да, не нужны, во
всяком случае на обычных системах для повседневной работы. (и опять почти
невозможно отключить)
Все эти kasr, stack guard, NX и прочие уродливые костыли - просто требуют
теперь чуть другой техники, которая и используется в каждом современном PoC,
и не кашляют.

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

Сейчас точно такой же вредной и ненужной херней занимаются вокруг проблем
процессора. Чтобы интелу, не дай Б-же, не пришлось нанять нормальных инженеров,
подорого. (если те еще вообще остались в нашем мире, а не пошли в веб-кодеры)

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

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

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


> Alex

--- ifmail v.2.15dev5.4

Alex Korchmar написал(а) к Victor Sudakov в May 18 10:44:42 по местному времени:

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

Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:

VS> Это в git (а лучше в hg) какая команда делает (отдать только часть изменений)?
cherry-pick

про hg лучше забудь, его придумывали не для ублажения Линуса и
прочих владельцев больших проектов, которые vcs используют "не для разработки",
а непойми для чего, там главная деталь - как раз вечность и необратимость
истории. Для работы с чужим проектом в hg принято использовать merge из
собственной ветки, которая никогда не пушится в апстрим. (и обратный
merge из апстрима, чтобы обновить свою ветку, а не rebase)

mq и rebase существуют, но придуманы в основном для ублажения
неосиляторов, выучивших единственный workflow, любимый Линусом -
"присылайте патчи в рассылку, порезав по две строчи и каждую завернув
в салфеточку". git автоматизирует именно такой.


> Alex

--- ifmail v.2.15dev5.4

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

09 мая 2018, среда, в 08:32 NOVT, Alex Korchmar написал(а):

AK>>> ни в каких. Это костыль. Затыкает один-единственный вариант атаки.
EG>> Ты говоришь так, будто фиксы против buffer overflow - каждого конкретного
EG>> в отдельности - тоже не нужны,
AK> фиксы в ядре системы или уродованием компиляторов - да, не нужны, во
AK> всяком случае на обычных системах для повседневной работы. (и опять почти
AK> невозможно отключить)
AK> Все эти kasr, stack guard, NX и прочие уродливые костыли - просто требуют
AK> теперь чуть другой техники, которая и используется в каждом современном PoC,
AK> и не кашляют.

Ты уже выпилил их все из ядер используемых линуксов и компиляторов?

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

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

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

EG>> Зато они требуют гораздо больше других вызовов и заточены под гораздо
EG>> более сложную модель разработки, которая мне solo не нужна.
AK> так и скажи - ниасилена.
AK> Нет там никакого "гораздо больше", и сложных моделей тоже нет.
AK> Просто система автоматической генерации и обработки патчей. Позволяющая
AK> вообще забыть об их существовании, и просто писать код. Придумана
AK> именно для ситуаций, когда код пишешь не для себя, любимого, и не
AK> все изменения годятся для апстрима.

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

git рассчитан именно на написание и отладку нового кода, да,
но это не про меня.

Eugene
--
И друзей успокоив и ближних любя,
Мы на роли героев вводили себя.
--- slrn/1.0.2 (FreeBSD)

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

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

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

AK>> Все эти kasr, stack guard, NX и прочие уродливые костыли - просто требуют
AK>> теперь чуть другой техники, которая и используется в каждом современном
AK>> PoC, и не кашляют.
EG> Ты уже выпилил их все из ядер используемых линуксов и компиляторов?
у меня ядро 3.0, в котором большей части этого мусора еще нет.
И, кстати, на столе у меня плата на D2700, где нет предсказания ветвлений.

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

EG> Так вот я не пишу код. Я изготавливаю патчи против багов,
EG> то есть патчи эти я изначально делаю вручную и поэтому
вручную ты модифицируешь - код. А не "патчи".

EG> git рассчитан именно на написание и отладку нового кода, да,
нет. Он рассчитан на то, чтобы забыть о "патчах" до момента, когда надо
их отдавать кому-то.


> Alex

--- ifmail v.2.15dev5.4

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

09 мая 2018, среда, в 12:30 NOVT, Alex Korchmar написал(а):

EG>> git рассчитан именно на написание и отладку нового кода, да,
AK> нет. Он рассчитан на то, чтобы забыть о "патчах" до момента, когда надо
AK> их отдавать кому-то.

Я не думаю в терминах кода. Я думаю в терминах багфиксов,
то есть правок к (уже существующему) коду.

Eugene
--- slrn/1.0.2 (FreeBSD)