#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 символов, но это не работает в случае статической линковки.

И к важным новостям: https://www.phoronix.com/news/KDE-Plasma-6-Double-Click

"KDE Plasma 6 Default Behavior Is Now Double-Click For Opening Files/Folders"

У телеги brain split на несколько независимых сегментов, интересно, к чему это?