Попробовал использовать mold в качестве основого линкера.

#bootstrap_science

Я как-то уже писал, что у меня есть возможность собрать целое поддерево с уникальным набором флагов. Это прямо незаменимый механизм для bootstrap. Потому что весь bootstrap можно выразить как последовательность шагов вида "собрать мешок инструментов версии N с помощью мешка инструментов версии N-1". #bootstrap

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

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

К сожалению, цепочка получается не очень робастной(ломается на каждый чих), и довольно ресурсоемкой. Но как источник вдохновения использовать ее можно.

Я еще раз подчеркну - с N-1 набором инструментов автоматически пересобирается все поддерево библиотек. Это на порядки упрощает конструирование цепочки bootstrap. Если бы ее пришлось переделывать на каждое новое добавление в цепочку по типу mold, то мне вручную бы пришлось описывать перестроение целого ряда библиотек. Например, для mold мне бы пришлось руками описывать сборочные файлы для boot-openssl, boot-intel-tbb, boot-xxhash, etc. А так все "само": https://github.com/pg83/mix/blob/main/pkgs/bld/mold/mix.sh#L4 (синтаксис уебищный, я там хочу что-то типа json, но мои задачи пока решает)

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

К сожалению, mold сыроват. На удивление, он слинковал все пакеты, но вот в одном случае у меня упал configure script вот с такой записью в log:

[15730.052723] conftest[4744]: segfault at 31 
ip 000000000020100b sp 00007ffdf79cae10 
error 6 in conftest[201000+1000]
[15730.052732] Code: 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 50 bf 3c 00 00 00 e8 
45 06 00 00 <00> 48 31 ed 48 89 e7 48 8d 35 
e7 ef df ff 48 83 e4 f0 e8 00 00 00

mold неверно слинковал какой-то тест для configure. Рестарт помог, и это совсем печально - ошибка нестабильна. Впрочем, это неудивительно, mold активно использует треды, и их тайминги - потенциальный источник нестабильности.

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

Даже не знаю, как сделать нормальный багрепорт в такой ситуации.

https://tass.ru/ekonomika/13923447

Чет много новостей затрагивает меня непосредственно. Я хотел на MacMini M1 строить CI для Mix. Пару раз писал тут, что M1 на 1 ядро в 4 раза быстрее собирает, чем доступные x86_64.

Пара MacMini казалась очень годной альтернативой облакам.

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

Если это не fake news, то это BIG news. Это же как надо было допечь сообщество-то, а?

https://maskray.me/blog/2022-02-27-analysis-and-introspection-options-in-linkers

Полезный текст про отладку линковки. Узнать, что линкер влинковал в финальный бинарь, и почему он занимает 300 метров, а не 3 - это полдела. Нужно уметь понимать, почему линкер принял то или иное решение, часто это совсем не очевидно.

Текст - обзор встроенных в разные линкеры средств отладки, почитайте, красивое.

———
https://sporks.space/2022/02/27/win32-is-the-stable-linux-userland-abi-and-the-consequences/

Интересный взгляд на ABI в Linux. Очень верное замечание про то, что вероятность того, что случайная программа под Винду, собранная 20 лет назад, имеет больше шансов запуститься на Linux, чем такая же программа, но собранная под Linux.

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

Это bullshit.

У Линуса очень однобокое понимание userspace ABI, и что нельзя ломать. AFAIK оно нигде не формализовано, но у меня за годы сложилось определенное его понимание.

Линус считает, что нельзя:

* ломать формат исполняемых файлов
* ломать формат системных вызовов

Это довольно слабый набор. Я, например, считаю, что в ABI входит и формат файлов в procfs, и в sysfs, и даже пути в /dev.

procsfs ломают довольно редко, но регулярно. Из последних примеров - acpid мне пишет в консоль, что какой-то файл в procfs имеет неверный формат, и что он фолбечится на другой механизм.

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

⚠️🇷🇺#russia #today

https://www.phoronix.com/scan.php?page=news_item&px=OpenBLAS-Russia-Elbrus-Issue

ебаный стыд

Аргументация, кстати, довольно разумная.

Напомню историю - аккаунты того "вандала", конечно, забанили.

Вот вам еще пример подобного вандализма:
https://github.com/arendst/Tasmota/commit/98cbf2587a1a914bbd16996ebb48dd451d3da448

Я думаю, сейчас мы узнаем, интернационален ли вандализм, или он тоже делится на рукопожатный(назовем его "вандализм за правое дело") и нерукопожатный.

Коллеги из MS, вы меня читаете, обратите внимание на ссылку.

Я, знаете ли, за равенство перед законом. Закоммитил код который намеренно что-то ломает - давай в бан.

Я постепенно приближаюсь к сборке хрома.

* Разбираюсь с depot_tools. Написал скриптец, который заменяет 95% depot_tools - генерит скрипт для загрузки исходников из кучи репозиториев.

https://github.com/pg83/mix/blob/main/pkgs/mix/scripts/deps.py

Он получился довольно простым, потому что я хорошо понял структуру файла DEPS - https://chromium.googlesource.com/chromium/src/+/master/DEPS

По сути, это кусок кода на питоне, который нужно eval 2 раза - в первый раз мы получаем переменные, которые нужно подсунуть во второй eval.

* Собираю зависимости. На целый день встрял со всратейшей nss/nspr от Mozilla. Я не понимаю, зачем хром стал от нее зависеть, ну да ладно. Some highlights:

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

- для сборки исходников нужны две системы сборки - КАСТОМНЫЙ autoconf(я не шучу)*, и gyp. Немного в сторону - мне кажется, Google наслаждается разработкой систем сборки и их opensource. Я не понимаю, зачем, но она склепала их уже штук 10(и это только известные мне). gyp - вторая по всратости их система сборки, хуже только Android.mk.

- вместо gyp можно использовать третий вариант - на чистых Makefile. Тут, конечно, как в том анекдоте - есть система сборки без бага, но не работающая(gyp), и работающая, но с багом(make)

- товарищи настолько стыдились этого говна, что решили не делать install target. Я не шучу. Устанавливать все надо вручную, экзерсизы на тему можно почитать, например, в сборочном файле для Alpine. https://git.alpinelinux.org/aports/tree/community/nss/APKBUILD Еще там можно восхититься мастерству maintainer по вырезанию лобзиком чего-то полезного из этого мусора. Так же можно обратить внимание на вручную написанные .pc файлы для pkg-config: https://git.alpinelinux.org/aports/tree/community/nss?h=master

- https://git.alpinelinux.org/aports/tree/community/nss/APKBUILD#n56 факт того, что за разрабами приходится дополивать сборку, намекает на то, что они не хотели, чтобы в чужих руках это собиралось.

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

Печальную историю про то, что все это говно вовсю использует dlopen(), я пока оставлю за кадром.

*UPD: не совсем верно написал. Не кастомный autoconf, а кастомную замену для automake, поверх которой работает обычный autoconf.

https://github.com/opengs/uashield #yeswecan #provider

"Voluntary Ukraine security platform to protect us from Russian forces in the Internet"

"protect us"

Так-то это инструмент для ddos. Гитхабу, кажется, насрать.

UPD: меня, конечно, возмущает не факт того, что там невозбранно лежит софт для ddos. Меня возмущает:

1) Неконсистентный подход. Похожие, по сути, вещи кому-то можно, а кому-то - нет.

2) Старая моя тема про то, что инфраструктурная площадка не может быть модератором самой себя. В данном случае в обратную сторону - недостаточная(даже по ее правилам) модерация. Прямым текстом - модерацию должны осуществлять люди, которым насрать на тонкую душевную организацию разработчиков этой площадки.

https://www.kommersant.ru/doc/5249015

Наше все Маск про цензуру. Маск, конечно, еще тот жук, достаточно вспомнить, как он своими заявлениями шатал крипту.

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

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

UPD: дополню мысль.

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

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

Короче, лекарство, которое всегда оказывается хуже болезни.

https://tjournal.ru/tech/554723-mincifry-reshilo-zamenit-inostrannye-sertifikaty-shifrovaniya-rossiyskimi-chto-eto-znachit-dlya-polzovateley-runeta

Вот, опять, про инфраструктуру. Центры сертификации должны удостоверять, что сайт - тот самый сайт, а не левая хня, и не более того.

Отзыв сертификата у крупного банка, например - это большой удар по экономике.

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

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

https://www.phoronix.com/scan.php?page=news_item&px=KDE-Lower-This-Week

"KDE Activity Lower This Week As Impact From The Russia-Ukraine War"

Класс. Я вот тоже взял отпуск на недельку, привести мысли в порядок :)

———
https://music.yandex.com/album/10330389/track/95874611

Не про IT. Коллеги очень советуют послушать, говорят, успокаивает.

———
https://ria.ru/20220305/gosduma-1776795432.html

"Госдума запустила официальный Telegram-канал"

Я думаю, что ни у кого уже нет сомнений, что "Наше все" Принципиальный Дуров с кем надо договорился. В целом, это неудивительно, после приснопамятных событий я, ради интереса, придумал пару способов как заблокировать телегу в РФ, ничего сложного в этом нет. Думаю, тогда власти были просто не готовы.

———
Одной строкой - хакеры, которые ломанули NVidia, в пятницу ничего не выложили.

Я так полагаю, что, на самом деле, у них были публичные требования и непубличные, вполне возможно, что непубличные и удовлетворили. Если я что-то упускаю, поделитесь ссылками, pls.

———
Писал как-то про то, что хочу начать контрибутить в OSS проекты свои патчи для Mix.

Я тут подумал, что довольно много из них общеполезно, как, например:
https://github.com/pg83/mix/blob/main/pkgs/lib/gtk/4/4/0.diff
(такой же есть и для gtk3)

Суть в том, что gtk использует свой механизм для настройки размера курсора, и это, например, ломается в sway, если руками не синхронизировать настройку в dconf/gsettings, и в sway. Я пофиксил это, взяв значение размера из переменной среды, которую устанавливает sway.

Шансы доехать до gtk у этого патча минимальны, потому что, как знают мои читатели, у gtk свой, особый, путь.

Короче. Не хочет кто-нить попробовать затащить это дело? Познакомиться с дистростроением изнутри, так сказать :)

Блин, забыл про веселую картинку в ленту!

В продолжение темы про модель безопасности. #sec_model

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

Еще 2 уязвимости, которые я считаю неважными. И некоторые соображения про их реализацию:

* всякие сложные модели безопасности плохо "компонуются", и получаются какими-то плохо взаимодействующими. Типа selinux + cgroups.

* чем сложнее система, тем сложнее про нее думать кожаному мешку.

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

Как иметь дело с inherent complexity? Я считаю, что с помощью иерархии - верхний уровень разделен на 2 слоя "все/ничего", в рамках каждого слоя можно запускать контейнер с таким же простым разделением.

https://miro.com/about/

Российская компания Миро удалила все упоминания о своем российском происхождении со своего сайта. В том числе, упоминание про офис в Перми. Офис, конечно, убрать так просто нельзя, поэтому его, в лучших традициях современности, "отменили" с сайта.

#bs #vendor #ix_run #dev_shell #gold

Меня удручает состояние современных OSS систем сборки. Расскажу сегодня про такой аспект: каждая уважающая себя современная система сборки хочет иметь в себе пакетный менеджер.

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

Cargo же все видели? Я пару раз писал, к чему приводит эта заявка на всеобъемлимость применительно к cargo - необходимость wrap все зависимости не под cargo в cargo сборку. Это выглядит уродливо, и приводит к проблемам с ромбоводными зависимостями.

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

Я уже писал про .wrap файлы от meson(для них существует целый репозиторий - https://mesonbuild.com/Wrapdb-projects.html).

Про это можно писать бесконечно, вот несколько очень всратых примеров:

* nodejs перепиливает сборочную систему от v8 на autoconf
* webkit переделывает сборочную систему от ANGLE(это реализация opengl от Google) на CMake
* chrome вендорит кучу библиотек, не буду описывать их по отдельности
* telegram вендорит все свои зависимости, и собирает их ни с чем не совместимым образом

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

Кстати, мне с этим живется несколько легче, чем там всяким fedora. В случае динамической линковки вендоринг - это еще и пересечение по путям в fs. В случае статической линковки это все хотя бы не видно наружу, достаточно де-вендорить всякие freetype/fontconfig и прочее.

Chrome, кстати, в этом отношении молодцы, они помогают де-вендорить те части, которые просто необходимо(типа рендеринга шрифтов).

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

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

Представьте себе команду

mix run lib/z lib/freetype bin/make 
    bin/cmake bin/clang/14 bin/ninja -- make -j 16

Эта команда сделает #realm , в котором будут доступны указанные библиотеки, указанные сборочные инструменты, и(вот тут важно!) врапперы для компилятора cc/c++/cpp (ну или rustc, кому что), которые автомагически настроят нужные пути к библиотекам и заголовочным файлам.

Кажется сложным? Ну давайте упростим это в alias mixrun=mix run $(cat mix.shell) —, и будем использовать так:

mixrun make -j 16

Или:

mixrun —sanitize=address —opt=-O2 make -j 8

Тогда в соответсвующем makefile вообще не нужно заниматься autodetect, перечислять всякие -I/-l-L/etc, а просто звать простые команды вида

cc -c x.o x.c

То же самое работает и для cargo, и для любой другой сборочной системы.

Основной point - система сборки уровня проекта не должна заниматься autodetect наличия зависимостей и их доставкой. Nix так умеет, Mix так умеет.

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

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

Веселая картинка в ленту!

https://www.phoronix.com/scan.php?page=news_item&px=MS-DX-HLSL-For-Upstream-LLVM

У меня сегодня негусто, но вот это IMHO большая новость. Microsoft хочет заапстримить в clang/llvm поддержку своего компилятора шейдеров для DirectX. Как часть этой поддержки, если я все верно понял, компиляция шейдеров в Vulkan SPIR-V. Очень надеюсь при жизни увидеть стандартизацию графического API на всех платформах :)