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, и с тем, что я выложил на своем сайте.

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

https://suricrasia.online/blog/turning-a-keyboard-into/

Отличный текст, с картинками, про то, как запилить свое виртуальное input устройство, например, мышь. Теперь от попытки запилить kinetic scrolling меня останавливает только своя лень. Ну и понимание, что, без связки с композитором, оно может работать всрато.

А я, кстати, рассказывал, как лет 10 назад запилил кастомный драйвер для synaptic touchpad? Меня здорово раздражала его "дубовость", но я посмотрел в его исходники, и понял, что ковыряться в этом не хочу. А еще раздражала необходимость перезагружать X при каждом изменении поведения.

Поэтому я запилил псевдо "драйвер" для X, который пытался присоединиться к определенному named pipe, и просто читал оттуда команды (в виде json rpc). А настоящий драйвер я запилил на питоне, он просто читал сырые события, парсируя какаую-то модную на тот момент утилиту для чтения сырых событий, и отправлял команды в другую сторону этого named pipe.

Понятное дело, что цикл Edit - Compile - Run стал в 100 раз быстрее, и нужного мне эффекта я добился довольно быстро.

А как смешно себя вела мышка, если вместо реальных координат отсылать координаты легкого тела, вращающегося вокруг более тяжелого тела, привязанного к реальным координатам, по законам Ньютона (проще говоря, передавать координаты Луны, как если бы Земля следовала за курсором мыши), ммм...

С++ #rant #gold

Мне сегодня в очередной раз сказали, что, мол, я люблю С++.

Это ложь, пиздежь, и провокация.

Давайте я вам расскажу краткий экскурс в развитие языков программирования, с авторским объяснением "что, как, зачем".

Тезис номер один. На ассемблере невозможно написать компилятор Rust. Вот вы хоть усритесь, хоть соберите 10^6 программистов с самыми таланливыми менеджерами. Не напишите, просто потому, что сложность компилятора Rust - просто гигантская, такую кодину, даже если ее суметь разработать по спецификации, будет невозможно отладить.

Из этого тезиса я делаю простой вывод - развитие идет маленькими шагами.

После ассемблера было неизбежным появление С и Алгол-подобных языков, типа Pascal. Pascal (в редакции с указателями) и С - это близнецы-братья. Их отличает то, что их можно довольно просто закодить на ассемблере, и они будут сносно работать.

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

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

Дальше у нас есть развилка - на C можно запилить:

* Интерпретатор с рантаймом (refcount или gc, это неважно), что-то типа lisp, python, perl, и так далее. Это прикольно для непосредственной разработки на этих языках, но, с точки зрения продолжения цепочки, это dead end, потому что ну не пилят промышленные языки на интерпретаторах с runtime.

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

Я говорю про C++ и про RAII.

(RAII, кстати, на мой взгляд, решает 80% ошибок управления памятью С, еще 15% фиксит санитайзер и valgrind, и 5% остаются на borrow checker)

Собственно, в конце 90-ых, начале двухтысячных, у меня было не особо много выбора.

Я пробовал Pascal, C, какие-то интерпретаторы. Интерпретация на тот момент была неюзабельной, потому что машины были очень слабые.

А на Pascal и C невозможно (ладно, запретительно дорого) строить большие программы, без постоянной боязни выстрелить себе в ногу (проездом или утечкой).

Поэтому я тогда выбрал С++.

Это был sweet point в языкостроении - компилятор еще не был перегружен тоннами наслоений, довольно простой язык, RAII давал писать гораздо более сложные и надежные программы, при этом, он был нативно-компилируемый.

Ну и, как полагается, С++ открыл дорогу к еще более сложным системам - Java, JS/V8/Node, Swift, два компилятора Rust написаны на С++, и я удивлен, что исходный зачем-то пилили на ML. Zig начинал с С++. Короче, по сути, вся плеяда современных языков выросла из этой приоткрытой двери. И я не говорю про language design, я говорю про простую и тупую вещь - на С++ можно было писать эффективные большие и сложные программы так, чтобы они почти не падали.

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

Я довольно хорошо знаю С++, но очень не люблю.

Почему?

Вторая часть марлезонского балета!

#abi

Потому что однажды создатели С++ добавили в него https://en.wikipedia.org/wiki/Turing_tarpit под названием "шаблоны".

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

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

И в этот момент ловушка для языка захлопнулась!

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

(пишу я это вполне осознано, как человек, когда-то спавший со стандартом под подушкой, и думавший, что он щас все сделает на этом сраном pattern matching под названием "частичная специализация")

Замкнутый круг.

Я вообще никому и никогда не советую начинать новые проекты на С++.

Лично я начинаю с Python, если неважен perf. В последнее время чаще смотрю на Go, и, думаю, однажды Go мне полностью Python заменит. Что бы я взял, если бы нужно было запилить что-то perf critical, в новой кодовой базе? Мне не нравится Rust, но, скорее всего, это был бы он.

(*) Что такое нормальное метапрограммирование? Это, по сути, доступ к AST (или, хотя бы, к потоку токенов) средствами самого языка, либо внешним кодогенератором:

* https://terralang.org/
* https://github.com/python/cpython/blob/main/Lib/collections/__init__.py#L439 - ядро изготовления namedtuple в python (да, кодогенерация + eval)
* lisp/scheme/etc
* в Rust норм

#gold #blob #supply

https://github.com/serde-rs/serde/issues/2538 этот тред, конечно, пополнит мою золотую коллекцию.

Разработчики serde (насколько я знаю, самая популярная библиотека сериализации для Rust), решили, что им "очень нада" ускорить сборку своего поделия, и положили предсобранную либу в свой репозиторий.

При этом, насколько я понял из объяснений в этом топике, библиотека не может быть собрана обычным образом из исходников (ну вот нельзя там где-то в Cargo.toml написать if). А заниматься патчингом уважающие себя дистрибутивы не хотят.

В тред набижали старшие и более опытные товарищи, и напихали хуев этим малолетним долбоебам объяснили, что так делать "не нада".

https://github.com/serde-rs/serde/issues/2538#issuecomment-1676139711
https://github.com/serde-rs/serde/issues/2538#issuecomment-1676355050

Вот, наверное, наиболее корректные сообщения с объяснением возникающих проблем при попытке воспроизвести сборку.

(От Jakub Jirutka, наверное, можно особо не объяснять, кто это?)

UPD: там, конечно, ЖЫР:

* Набижали SJW со своими "community deserves more" (я, как последовательный правый, считаю, что сообщество заслуживает только того, что написано в лицензии) https://github.com/serde-rs/serde/issues/2538#issuecomment-1684526456

* Или вот автор форка этой либы, который пишет, что сам не хочет его поддерживать, и есть ли на это волонтеры. https://github.com/serde-rs/serde/issues/2538#issuecomment-1684531496

* А кто-то предлагает скинуться по 10 баксов автору либы, чтобы он сделал эту фичу opt-out - https://github.com/serde-rs/serde/issues/2538#issuecomment-1684607407

Будни #bootstrap

Я, как вы уже заметили, люблю собирать запчасти для #stal/ix с разными там выподвыпердами.

Например, базовые программы у меня собраны со стандартным аллокатором из musl (потому что там важнее размер бинаря, а не скорость аллокации), и с netbsd curses вместо ncurses. Тоже из-за экономии размера, ну и потому, что там terminfo database вкомпилена в либу, а не валяется в виде 100500 файлов на диске, как у ncurses. Так же из них выпилены gnu gettext, потому что нефиг.

Выглядит это так - https://github.com/pg83/ix/blob/main/pkgs/set/system/0/ix.sh#L4 Фактически, собираю поддерево проектов с особым набором флагов, которые переключают те или иные умолчания.

Вот, нашел на просторах интернета hardened malloc - https://github.com/GrapheneOS/hardened_malloc, и решил, что мне обязательно нужно собрать с ним единственную программу, которая у меня в системе занимается privilege escalation - sshd (https://xn--r1a.website/itpgchannel/291).

Не то чтобы я очень боялся, что ее взломают, но зумеры и хипстеры же падки на такие заявления - "security enhanced base system, with hardened malloc" etc etc и прочий bullshit.

https://github.com/pg83/ix/blob/main/pkgs/bin/sud/ix.sh#L7 - вот, буквально одна строчка изменений, помимо того, чтобы положить саму либу в репозитоий.

Fun fact:

В процессе линковки "усиленного" dropbear выяснилось, что кто-то у кого-то потырил исходники:

ld.lld: error: duplicate symbol: chacha_keysetup
>>> defined in ./libssh.a(chacha.o)
>>> defined in .../libhardened_malloc.a(chacha.o)

ld.lld: error: duplicate symbol: chacha_ivsetup
>>> defined in ./libssh.a(chacha.o)
>>> defined in .../libhardened_malloc.a(chacha.o)
ld.lld: error: duplicate symbol: chacha_keysetup
>>> defined in ./libssh.a(chacha.o)
>>> defined in .../libhardened_malloc.a(chacha.o)

ld.lld: error: duplicate symbol: chacha_ivsetup
>>> defined in ./libssh.a(chacha.o)
>>> defined in .../libhardened_malloc.a(chacha.o)
ld.lld: error: duplicate symbol: chacha_keysetup
>>> defined in ./libssh.a(chacha.o)
>>> defined in .../libhardened_malloc.a(chacha.o)

Обычно такое скрывают с помощью всякого рода hidden символов, но это не работает в случае статической линковки.