вышел go 1.18

С дженериками.

https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md

Я пока не осилил прочесть этот текст, коллеги, там type erasure или мономорфизация?

Я, конечно, надеюсь, что первое, потому что и дальше можно будет ходить и говорить "дженерики в go - говно"(вместо "в go нет дженериков").

———
https://lwn.net/Articles/887746/

#linux #ci

Мне уже несколько поднадоело писать про то, как linux hackers относятся к тестам, но вот эту цитату Линуса я не могу пройти стороной:

"None of this was really surprising, but I naïvely thought I'd be able
to do the final release this weekend anyway.

And honestly, I considered it. I don't think we really have any pending issues that would hold up a release, but on the other hand we also really don't have any reason _not_ to give it another week with all the proper automated testing."

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

Норм.

———
https://github.com/terraform-aws-modules/terraform-aws-eks/pull/1937#issuecomment-1068308469

Вчерашний мой PR закрыли. Дискуссия интересная, по очкам я победил, но хозяин - барин.

Я, конечно, продолжил дискуссию в новом тикете, но меня там послали, и тикет просто отменили, как это сейчас принято.

Потом автор всего этого безобразия нашел мой канал, и пришел в прошлый пост, почитать можете сами.

Девочка Антон продолжает познавать #git.

Внезапно обнаружил, что, с моим CI, мне удобнее вести green trunk через merge flow, а не через rebase flow.

Вот, у меня есть своя ветка https://github.com/pg83/ix, я туда пушу обновления почем зря, потом, когда появляется время, начинаю смотреть в свой #CI, и пушить фиксы сборки и тестов. Эта ветка, конечно, использует rebase flow, и мой любимый стиль "better".

В какой-то момент моя ветка становится зеленой, и ее надо интегрировать в green trunk.

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

По идее, можно было бы как-то помечать ссылки на зеленые коммиты, но вот мне показалось удобным помечать их как "merge commit".

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

Конечно, я хотел бы что-то типа монорепного зеленого транка, но, кажется, это не будет хорошо работать в ситуации, когда ты, в среднем, не доверяешь контрибутору (а у меня, например, CI не изолирован, поэтому перед тем, как отправить PR в CI, я хочу его отсмотреть).

#linux #kernel #ci

https://www.phoronix.com/news/Linux-6.8-Sched-Regression

TL;DR - в процессе слияния ядра 6.8 Линус заметил, что, когда он собирает свежее ядро, будучи загруженным в это свежее ядро (#bootstrap), то у него это ядро собирается в 2 раза медленнее.

Тут, конечно, интересна не причина регрессии, а процесс.

Даже до Миши с фороникса начинает доходить, что что-то в консерватории не так, если такие валенки на пульте находит не автоматизированный CI, а лично Линус в процессе мержа:

"For regressing a workload like code compilation speeds being halved is rather surprising as while the Linux kernel lacks common and robust continuous integration (CI), it seems like kernel developers responsible for the changes would notice such a dramatic change... Especially if the code has been through linux-next and the like"

Все, буквально все (кроме старых линуксхакеров - https://t.iss.one/itpgchannel/264), уже понимают, что одна из самых важных программ в индустрии не может разрабатываться ТАК. Ну, то есть, может, но только в 10 раз медленнее, или дороже, чем могла бы.

Треш, угар, содомия.

Особенно смешно на этом фоне смотрится, как Линус материт Intel за то, что они не тестируют свой код перед мержем - https://www.phoronix.com/news/Torvalds-Unhappy-Linux-6.8-DRM

Я, когда писал вот этот вот текст, про то, что rust с его каргой - тихий ужас, с точки зрения дистростроения, тогда еще не имел в своем #CI программ на #rust.

А теперь у меня их порядка 20 штук, и, я должен сказать, что https://t.iss.one/itpgchannel/337, как говорится, не "в бровь, а в глаз".

Потому что мой CI половину (половину, Карл!!!) времени занимается тем, что пересобирает эти несчастные 25 программ. Напомню, что всего у меня порядка 2000 пакетов, и вот где эти 20 программ, и где половина времени моего CI?

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

Но я выкрутился тем, что отселил CI для растопрограмм в отдельный контур, на отдельный, более слабый, хост (64 ядра vs 88 в основном контуре). Ну и оно там "как-то" бежит, не замедляя весь процесс.

Я не знаю, какой-нибудь сраный https://github.com/zed-industries/zed - это 1200 крейтов в зависимостях. 1200, Карл!!! Это больше, чем просто библиотек в среднем дистрибутиве Linux! Для сборки текстового редактора! 1200 библиотек!

Меня, признаться, знатно подбамбливает от всей этой экосистемы, так жить нельзя.