https://github.com/facebook/zstd/issues/3717

Тут вот коллега поднимает бучу по поводу лицензии ZSTD.

Вся мякотка заключается в том, что используется двойное лицензирование, но, вместо того, чтобы написать BSD OR GPL, там написано BSD AND GPL. Как говорится, есть нюанс.

Коллега предлагает исправить текст на OR, но, КМК, он не очень понимает, что он предлагает на самом деле (или, наоборот, очень хорошо понимает, why not). Потому что facebook не может просто взять и заменить текст на OR, для этого нужно получить согласие от всех контрибуторов в zstd, а это, конечно, ад и израиль.

https://kipp.ly/jits-impls/

Вот, например, хороший текст, откуда я узнал, что GraalVM https://www.graalvm.org/ - это не только очередная блажь от оракла, но что-то действительно интересное, и, даже, может быть, полезное.

Идея про "погрузить С в LLVM bitcode для интерпретации и JIT в JVM для более простого interop" - это прямо хорошо.

https://gist.github.com/pg83/aabbfa4e0850f3616857d9acaaf841c8

А вот вам еще одна всратая ошибка сборки, из-за криворуких атворов #cmake.

Что тут произошло?

Я в каждую папку с готовыми артефактами кладу файлик touch, как символ того, что эта папка готова.

А авторы #cmake решили, что они будут искать бинари не только в папках CMAKE_PREFIX_PATH/bin, а еще и в самих CMAKE_PREFIX_PATH. И вот сборка webkitgtk нашла такой файлик в качестве команды touch - https://github.com/WebKit/WebKit/blob/main/Source/JavaScriptCore/CMakeLists.txt#L159

Знаете, вот это вот ощущение, когда одни криворукие программисты начинают воркэраундить код для других криворуких программистов (одни не сумели осилить передать правильный PREFIX, другие не рабобрались, и стали искать везде)?

Вот это вот оно, да.

Полгода назад запилил свой великолепный CI скрипт, https://github.com/pg83/ix/commits/main/pkgs/die/scripts/ci.

По сути, он почти не менялся, кроме того, что я вынес внешний цикл в #runit, ну а так он работал себе и работал.

Но вот недавно я добавил туда ровно одну строку, которая призвана собирать все то же самое, но другим выполнителем графа - https://github.com/pg83/ix/blob/main/pkgs/die/scripts/ci#L8.

Напомню, у меня их два - один на go, он ставится в систему, и служит для оркестрации выполнения для #stalix, а второй написан на питоне, и служит для #bootstrap, ну и на macOS можно чего-нить пособирать. Так, простенький выполнитель, встроенный прямо в движок построения этого графа.

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

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

Интересно, сколько я его теперь смогу не трогать?

https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9B%D0%B8%D0%BD%D1%83%D1%81%D0%B0

Вот есть 3 популярные в open source системы сборки - cmake, meson, #autohell.

И во всех трех есть определенные проблемы с #cross-компиляцией:

* В #cmake ее просто нет. Много раз писал и буду писать, что она у него совершенно фейковая, для отчета горе-программистов, которые ее делали, перед начальством.

* GNU #autohell содержит зачатки кросс-компиляции (умеет искать host compiler, например), но дальше ты сам по себе - фактически, нужно руками писать все сборочные правила для host сборок, без всякой на то помощи. Искать host библиотеки через pkg-config? Боже упаси, это же просто космос!

* meson наиболее продвинут в этом отношении, но и в нем есть свои проблемы. Например, очень странный способ указывать host/target тулзы, через материализованный файл, с не очень понятным синтаксисом.

При этом, ни одна из этих систем не является cross-native (#cross_native)!

(я сам изобрел этот термин, не ищите)

Что это значит?

Это значит, что кросс-компиляция туда добавлена постфактум, и не является родной. То есть, по умолчанию, предполагается, что ты можешь запустить любую свежесобранную тулзу, а чтобы было "не так", разработчики конкретной сборки должны знать, что бывает кросс-компиляция, и специально для этого присесть (повторю, meson в этом помогает, autohell не мешает, cmake мешает активно).

При чем тут закон Линуса?

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

Как я предлагаю поступать с кросс-компиляцией в open source?

Я советую:

* Или писать весь код, который надо запустить на host системе, на интерпретируемом языке, типа python.

* Или разбивать свои проекты на библиотеки и программы в разные проекты на github (или в разные папочки одного проекта, но с возможностью собрать по отдельности все составляющие части), и сопрягать их мета-сборкой, типа nix/ix/guix.

#security #CVE

Меня тут спрашивают, почему я не пишу про всякие интересные уязвимости в CPU, типа

https://www.opennet.ru/opennews/art.shtml?num=59571
https://comsec.ethz.ch/research/microarch/inception/

Я не знаю.

Это было интересно в первый раз (а все помнят название первой уязвимости такого класса? Я вот уже забыл).

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

Я бы тут поспекулировал, что это вообще свойствено уязвимостям.

Когда их сложно найти, и легко починить, то почет и уважение тем, кто их ищет, почет и уважение тем, кто их фиксит, все довольны, все получили свою 5+, и всем пофиг, что ущерб не нанесен, потому что in the wild оно не эксплуатировалось.

А вот когда починить реально дорого, прямо очень дорого, то люди ВНЕЗАПНО вспоминают, что умеют считать деньги, и просто игнорируют всю эту шелуху и весь этот абсурдный театр безопасности.

Про идеальный код.

У меня есть друг, он однажды сказал такую фразу, поменявшую мои представления о коде, и о программировании.

"Представь себе", сказал Ден (его зовут Ден, да), "что ты импотент". "У тебя есть два пути - всю жизнь жаловаться на это и страдать, а можно привязать карандашик, и таки впендюрить" (цитата дословная).

Не то чтобы это сразу во мне что-то поменяло, но я это запомнил, и потом много лет занимался тем, что, по капле, выдавливал из себя свое (часто неуместное!) "чувство прекрасного", которое сильно мешало жить программировать, и делать сложные и интересные штуки.

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

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

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

#fork

https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license

#HashiCorp вычеркивают себя из open source. Флаг им в руки, но не думаю, что у них выйдет из этого что-то хорошее.

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

"Rocky Linux, Oracle и SUSE создали совместный репозиторий для RHEL-совместимых дистрибутивов"

Вот, пишут об образовании антигитлеровской коалиции компаний, желающих раздать всем RHEL, и бесплатно.

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

Разработчик https://github.com/moq/moq решил, что ему надо как-то заработать на своем open source проекте (как уже знают мои давние читатели, я очень скептически отношусь к этой идее).

Для этого он запилил в свой проект (я так понимаю, в сборку своего проекта) какую-то малварь, которая проверяет, зарегался ли пользователь в качестве спонсора этого проекта, или нет - https://www.cazzulino.com/sponsorlink.html

https://github.com/moq/moq/issues/1374 - тикет с обсуждением этого гениального решения. ЖЫР, много ЖЫРА. Читайте, пока не потерли.

https://github.com/go-task/task/issues/820

Вот, как выяснилось, коллеги тогда отправили баг в трекер.

Не прошло и года Примерно через год туда набижали разработчики, и предложили сделать эту величину настраиваемой. А еще автоматически подстраивать это значение, если у тебя в таске есть цикл. Надо им рассказать про https://en.wikipedia.org/wiki/Total_functional_programming

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

Мораль?

А нет ее, не знаю. Скоро вот все chatgpt перепишет, будет софт дешевый, его будет много, и он будет глючный.

Я бы хотел написать заголовок "будни #bootstrap", но случай произошел со мной на day job. Но, так как он очень в тему, напишу сюда.

Все началось с того, что программа на go, использующая cgo (это важно), при смене toolchain с llvm14 на llvm16, начала падать вот с такой странной ошибкой:

pg: ./go_...
runtime: pcHeader: magic= 0xfffffff1 pad1= 0 \
    pad2= 0 minLC= 1 ptrSize= 8 \
    pcHeader.textStart= 0x1c5640 \
    text= 0x555555719640 \
    pluginpath=
fatal error: invalid function symbol table
runtime: panic before malloc heap initialized

В интернетах по тексту этой ошибки находится довольно много чего, например, https://github.com/golang/go/issues/43969, но ничего из найденного мне не помогло.

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

Но сюда я сразу напишу короткую цепочку проблем, которая и приводит к такому падению.

go runtime настаивает на том, что

pcHeader.textStart

должен быть равен

text

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

Сначала я подумал, что это ASLR, но его отключение мне не могло.

Ключом к разгадке стал вот этот сеанс в gdb - https://gist.github.com/pg83/a1453493d4b01ab4ee267faf6629d99a Это ряд команд, которые сделаны над падающей программой. А вот то же самое, но в программе, слинкованой с llvm14 - https://gist.github.com/pg83/e5746531e5a571743d50c107bb59b7ee

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

Вывод?

В первом случае программа, после загрузки, была релоцирована в более высокие адреса. Это так же видно, если сравнить два strace, до и после:

< execve("./b", ["./b"], ... = 0
< brk(NULL)                  = 0x5555556ef000
---
> execve("./g", ["./g"], ... = 0
> brk(NULL)                  = 0x391000

Видите? Первый же brk возвращает более выской адрес.

Если же программу слинковать с musl, полностью статически, она начинала работать.

Стало понятно, что программу релоцировал динамический загрузчик из glibc. Но какого хера он это раньше не делал, а теперь начал делать?

Дальше это было дело техники - https://discourse.llvm.org/t/llvm-15-default-pie-issue/67125

Оказывается, в 15 llvm коллеги перешли на -fpie по умолчанию, то есть, они всегда строят релоцируемый выполняемый файл. А go runtime оказался к этому не готов. И очень хорошо, что коллеги добавили этот panic, потому что без него искать рандомные сегфолты было бы очень сложно, и (еще более) неприятно.

Как починил? Отменил эту опцию для линковки go-шных программ. Ну а потом и вообще отменил, слишком уж много странных ошибок в тестах начало случаться.

#security

https://github.com/CuBeRJAN/nix-problems

А вот, например, неплохой список проблем в Nix. С удовольствием читаю такое, потому что, в каких-то аспектах Nix мой прямой конкурент, и хочется сделать лучше.

С некоторыми тезисами оттуда я совершенно не согласен, например, жалоба на то, что коммиты в nixpkgs не подписаны. И ссылка на обсуждение https://github.com/NixOS/rfcs/pull/100.

Я не понимаю необходимость подписи коммитов. Мне не нужно знать кто мне прислал коммит с фиксом сборки пакета. Мне его нужно прочитать, запустить на него CI, после чего я принмаю на себя грех ответственность, и публикую его у себя.

То есть, мой результат - это git sha, который является комбинацией моего предыдущего дерева, и нового changeset.

Если вы получили один и тот же git sha с github, и с моего независимо работающего сайта, где я публикую свежие релизы, то чего же желать еще?

В продолжение темы про подпись коммитов.

Предлагаю вам такой setup:

* Есть два независимых (с точностью до того, что мы ниже можем умножать вероятность) канала, которые умеют выкладывать tgz с программой.

* Есть я, который по какому-то другому, надежному, доверенному каналу донес до вас следующую мысль - "на вот эти вот два канала tgz выкладываю я, и только я". Например, выступил на конференции воочию.

* Известно, что я доверяю этим двум каналам, то есть, могу скачать (независимо) с них tgz, и проверить, что они совпадают с тем, что выложил на них я.

Утверждение - если вы скачали один и тот же tgz с этих двух каналов, то вы можете быть уверены, что его выложил я, с очень большой вероятностью, равной 1 - a*b, где a, b - (небольшие) вероятности того, что взломали первый, или второй канал.

Коллеги, тут нигде не возникает необходимость в подписи.

Тут нигде не возникает необходимость вам доверять одному из этих каналов.

Тут важно доверять только мне, что я не выложил какую-то левую фигню.

И важно скачать tgz по обоим каналам, и убедиться, что они одинаковые.

Можно не качать tgz, можно сравнить git sha с тем, что скачано с github, и с тем, что я выложил на своем сайте.

Вот реально, не понимаю, почему такая простая математика вызывает столько споров.