Увожаемые, а дайте совет про лучшие практики CI на github?

Сейчас у меня есть процесс, который на каждый коммит умеет сказать OK/FAIL.

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

А как вообще принято?

https://sourcehut.org/blog/2023-01-09-gomodulemirror/

Продолжение истории про ddos от Google.

Решение Дрю, конечно, спорное, потому что принципы - принципами, но вот go-шные проекты у него хостить будет сложнее.

https://quick-lint-js.com/blog/cpp-vs-rust-build-times/

Текст про сравнение скорости сборки Rust vs. C++.

От кучи подобных текстов отличает монументальность подхода - коллега переписал 17 тыщ строк с С++ на Rust, для корректности сравнения.

Измеряется вообще ВСЕ - инкрементальные vs полные сборки, различные трюки для ускорения сборки как С++, так и для Rust, в том числе, (за это отдельный респект и уважуха) - попытка собрать тулчейны с #BOLT.

Короче, автор явно одержим скоростью, почитайте.

Выводы? Все сложно!

Коллеги принесли красивое.

Обсуждали внутренний патч во flakes8, вида

-VALID_CODE_PREFIX = re.compile(
    "^[A-Z]{1,3}[0-9]
    {0,3}$", re.ASCII)
+VALID_CODE_PREFIX = re.compile(
    "^[A-Z]{1,3}[0-9]
    {0,4}$", re.ASCII)

Ну, типа, не хватает ширины какого-то поля, давайте, мол, увеличим на 1.

Конечно, возник вопрос - почему так в upstream, и можно ли это будет смержить в него.

https://github.com/PyCQA/flake8/pull/1782#issuecomment-1377346615
https://github.com/PyCQA/flake8/issues/1777

TL;DR - начнем с того, что ты пиздоглазое мудило "what part of "this is not changing" do you not understand?"

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

А, ну и вишенка на торте - договориться не могут проекты(pylint и flake8) из одной организации.

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

https://seclists.org/oss-sec/2023/q1/13

Просто оставлю это здесь.

На самом деле, из текста я не понял, где именно не случается нужная проверка. Я вот, например, при скачке исходников тоже не проверяю сертификаты, потому что важнО несовпадение чексуммы(SHA), которая получена по надежному каналу.

Если при скачке репозитория версий и зависимостей - то это, конечно, хорошо.

Вчера разбирались с коллегой, почему у него странно работает ssh на машину с установленным #stal/ix.

Если совсем коротко, то это выглядело так:

# ssh host env
...
A=B
...
# ssh host
> env
...
A=C
...

Ну, то есть, натурально, сильно разный environment при запуске команды в batch режиме ssh, и такой же команды в интерактивном режиме.

Дело свелось вот к этой функции - https://github.com/mkj/dropbear/blob/master/dbutil.c#L371

Совсем коротко - для интерактивного режима оно запукает shell в login mode, и тогда shell читает содержимое /etc/profile, и далее все, как положено, а для запуска batch команды запускает шел в неинтерактивном режиме, через -c. Ну и этот shell, конечно, наследует env от parent process, и не зачитывает на старте /etc/profile.

Я тут не очень понимаю, как правильно (и кто это "правильно" вообще определяет).

Мне лично кажется, что и во втором случае нужно запускать login shell, но не в интерактивном режиме!

Я это у себя зачинил так - https://github.com/pg83/ix/blob/main/pkgs/bin/dropbear/ix.sh#L7 https://github.com/mkj/dropbear/blob/master/dbutil.c#L388 - вот тут заменяем -c на -cl, указывая, что надо зачитать env из /etc/profile.

Вот теперь думаю, надо ли с этим стучаться в dropbear upstream, или меня там сразу нахер пошлют?

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

Если коротко - то меня бесят многие вещи, сделанные в Unix/Linux, и самый простой способ их починить - это иметь контроль над всем окружением!

Вот, если говорить про предыдущий пост, где я написал про "странность" поведения ssh daemon в интерактивном vs. batch режиме.

На самом деле, эта странность очень просто объясняется - она вызвана путаницей между login shell, и interactive shell!

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

Но это в корне неверно!

Login shell, это, если очень грубо, первый shell в цепочке для вашего пользователя. Обычно его стартует какой-нибудь display manager, типа mingetty, agetty, emptty, greetd, sddm, да тысячи их. ssh, putty, telnet, mosh, и так далее - это тоже штука, которая spawn первую shell в цепочке!

Interactive shell - это то, куда вы вбиваете команды с клавиатуры.

Это, конечно, довольно разные штуки.

(Кстати, немного в сторону - если у вас бывают случаи, когда в PATH повторяются одни и те же элементы - это значит, что вы не понимаете разницу между этими сущностями, и у вас иногда два раза срабатывает конструкция добавления чего-то к PATH, потому что лежит не в том файле)

Проблема тут еще усугубляется тем, что разные shell читают разные startup файлы, в зависимости от режима.

Например, bash читает /etc/profile как и в interactive, так и в login mode. А большинство других shell так не делают!

Короче, тут явно видны треш, угар, и содомия, наслоение привычек, непонимания, и так далее. Оцените, например, только /etc/environment - https://superuser.com/questions/664169/what-is-the-difference-between-etc-environment-and-etc-profile - это упячка, родившаяся из того, что иногда надо сделать "login", но без "shell", а переменные откуда-то надо взять!

Поэтому, конечно, я тут намерен сделать все "правильно" (*), а не воспроизвести хак, к которому все привыкли!

Почему?

Потому что, если бы меня устраивал этот хак, я бы поставил Fedora! А мне нужно better!

(*) Правильно - конечно, ssh и прочие должны запускать первый shell в login mode. Еще лучше - для каждого shell пользователь должен разобраться, в какие файлы ему класть interactive настройки (типа completion), а куда - login.

https://xn--r1a.website/PAAMAYIM_NEKUDOTAYIM/30

Не могу не утащить из комментариев!

Продолжается замечательная история про #gil в Питоне.

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

https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional/22606

Я настроен довольно пессимистично, потому что люди прекрасно понимают, что это сильно фрагментирует экосистему. Условно говоря, будешь ты приходить к автору third party модуля с просьбой починить в нем баг в многопотоке(или починить регрессию в однопотоке), а он будет посылать нахер, с "не использовали многопоток, и неча начинать". В итоге, все разделится по признаку "можно в многопоток/нельзя", и это не очень.

https://www.opennet.ru/opennews/art.shtml?num=58472

Пишут, что в Chromium можно в Rust.

Новость, конечно, не очень приятная!

Я люблю, когда на Rust переписывают какую-то кодину на C, но вот сочетание Rust + C++ мне не очень ОК. Потому что С++ достаточно безопасен, настолько, что проблемы от взаимодействия 2 языков перевешивают профит. Про такую попытку Гугла использовать Rust в С++ кодовой базе я уже писал - #cras.

"Для упрощения интеграции кода на Rust с существующим кодом на C++ и обхода связанных с интеграцией рисков и ограничений, в настоящее время решено ограничиться однонаправленным взаимодействием - обращением из С++ к Rust (т.е. код на Rust может лишь вызываться из кода C++ через функции API, но не смешиваться с кодом на C++), что также даст возможность держать под контролем дерево зависимостей. Вторым ограничением является поддержка только сторонних библиотек, поставляемых в форме отдельных компонентов, не привязанных к Chromium и имеющих API, ориентированный на выполнение конкретных задач"

Пока мне кажется, что это такой эксперимент, и что эти правила позволяют затащить какой-то кодек на Rust, или вот librsvg. Вполне возможно, что этим все и ограничится, как двумя файликами "для галочки" в #cras.

И еще такой вопрос - а что с #carbon?

Кажется, что Rust тут пытается откушать как раз нишу #carbon, и это довольно странно. Carbon все?

https://www.opennet.ru/opennews/art.shtml?num=58465 #sfc

Слуште, я, когда прочитал текст этой новости, полез в календарь, и проверил, какое сегодня число. Но потом увидел, что, в списке подписантов, есть известные левые упыри под названием #sfc, и все встало на свои места.

Интересно, много ли народу съехало с github, после их прошлой инициативы?

Такие IT новости нам по душе! Хотя я бы, конечно, ожидал бы такого от blizzard!