Как понять, что у компании дохуя денег, и что их вот вообще некуда девать?

Если компания:

* Пытается пропихнуть свою вполне обыкновенную шину в ядро, аргументируя это несуществующими преимуществами в performance

* После неудачи пыдается запилить это в виде никому не нужного out of tree модуля https://github.com/bus1/bus1 #kdbus

* Потом пишет супер-эффективный(наверное, на самом-то деле эту херню никто не компилировал, не то что не запускал) https://github.com/bus1/dbus-broker, который должен научить уметь эту шину в 1KK RPS, хотя ей, по всем измерениям, достаточно и 1RPS

* А в финале(?) говорит "а давайте запилим что-нить на current hype language под этой umbrella" https://www.phoronix.com/news/BUS1-r-linux

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

Я таки научился решать эту проблему без bc от busybox.

Нет, не починил гнутый, а нашел еще одну реализацию, которая заявляет, что совместима со всеми известными реализациями - https://git.yzena.com/gavin/bc

Кстати, от того же #gavin, который написал классный текст про статическую линковку, и от того же #gavin, который придумал свою OSS лицензию для борьбы с #copilot.

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

Ядро с этим bc прекрасно собралось, и работает.

В комментариях как раз обсуждали landlock, и на тебе, Justin подогнала gnu make + landlock: #justine

https://justine.lol/make/

TL;DR; - make сам ограничивает свои ноды выполнения по тому, куда им можно писать и что можно читать.

ЖЫР:

"To demonstrate this, I've configured this repository to compile 448 .c files which are linked into 40 executables. Building 448 files in 448 different sandboxes takes:

3.0 seconds with Make
11.6 seconds with Bazel"

Тут мы ее, конечно, поправим, что в Bazel и прочих ya/buck/etc дело не только в контроле зависимостей, а еще и в том, как они проверяют необходимость пересборки(content addressable store, чего gnu make не умеет и никогда не будет уметь).

Ну и, видимо, в bazel executor написан на java, и тормозит при fork + exec, поэтому 500 небольших .c файлов имели большой overhead.

Уверен, что executor на C++(как в ya, например), или даже на Go(как у меня) справились бы не хуже, чудес же не бывает.

Поэтому тут Жастин я ставлю жирный минус, она или не разобралась, или троллит, или ищет дешевый PR для своего решения.

Более четко поясню свою мысль.

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

Говорить что проверка зависимостей ускорилась в разы по сравнению с Bazel - методологически некорректно, предложенное измерение этого не показывает.

Медленно продираюсь через сборку chromium, и она меня, конечно, очень бесит.

Пока как-то так:

"[11727/51727] CXX obj/third_party/dawn/src/dawn/native/sources/PipelineLayoutVk.o
[11728/51727] CXX obj/third_party/dawn/src/dawn/native/sources/DeviceVk.o
[11729/51727] CXX obj/third_party/dawn/src/dawn/native/sources/FencedDeleter.o
ninja: build stopped: subcommand failed.
subcommand error: [/ix/store/JXJCJ6NtAEXKZFAY-bin-chromium/touch sh -s] failed with exit status 1"

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

Например, он полагает, что libc идет из системы, и он полагает, что это glibc.

Поэтому, блин, сраный nasm, который он тоже вендорит, оказывается скофигурен под glibc, и не собирается с musl, а вот стоковый nasm, после запуска своего же configure - собирается. Для меня - это повторение уже сделанной большой работы, по запуску того или иного инструментария в моей среде.

Кстати, список патчей от alpine linux, для сборки под musl - https://git.alpinelinux.org/aports/tree/community/chromium?h=master

Опять же, chromium считает, что mesa и драйвера для 3d идут из системы, а vulkan loader он использует свой, собирает свои же компиляторы шейдеров, и так далее.

Завязки на сборку с x11, раскиданные всюду.

Причем, что интересно, если взять их сборку для внешних людей, то завязки на X11 нет - https://android.googlesource.com/platform/external/swiftshader/+/refs/heads/master/src/WSI/CMakeLists.txt#35

А в сборочном файле "для себя" - есть. https://android.googlesource.com/platform/external/swiftshader/+/refs/heads/master/src/WSI/BUILD.gn#37

Сейчас затык в том, что загрузчик для vulkan они хотят свой, и он как-то не очень совместим с тем, с которым я собирал mesa.

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

Но бесит это, конечно, люто и бешено.

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

КМК, мое решение проблемы в supply chain по ссылке проще - надо просто исключить кожаный мешок из подготовки релиза, пусть tgz готовит система контроля версий.

#npm не нужен

Вот просыпаешься такой, в прекрасном настроении, а тут война авторы swift решили его переписать на swift. #bootstrap

https://forums.swift.org/t/implementing-parts-of-the-swift-compiler-in-swift/59524

Треш, угар, содомия.

Я, конечно, не смог удержаться. https://forums.swift.org/t/implementing-parts-of-the-swift-compiler-in-swift/59524/33

Я уже как-то писал, что по сборочному графу можно много понять про собираемый софт. #jpeg_xl

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

https://git.sr.ht/~pg/ix/commit/11dc857512d68161153005fe8e27fff243fcd855

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

https://en.wikipedia.org/wiki/JPEG_XL

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

Например, разрешив писать плагины для какого-то безопасного представления, типа #wasm.

В целом, идея звучит здраво, скажем, более здраво, чем загрузить случайную .so в себя, но, как мне кажется, пока недостаточно здраво:

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

* wasm пока довольно lightweight, но почему он через 5 лет не станет очередной JVM, не очень понятно. Стали ли бы вы к себе влинковывать JVM, чтобы безопасно исполнять плагины?

* Даже если предположить, что JIT будет не влинкован в каждое приложение, а будет общесистемный демон, который по bytecode будет возвращать объектный код, то, все равно, такой объектный код все равно опаснее, чем интерпретация, или запуск в отельном процессе.

Короче, хорошо, но, КМК, недостаточно хорошо.

Какой-нибудь очень простой wasm-интерпретатор, для не критичных к CPU блоков кода, мне кажется более интересным.

Ну и, если вы браузер, и уже притащили к себе wasm jit, то почему бы вам не скомпилировать просмотрщик PDF в WASM? Вот в этом не вижу ничего плохого, только хорошее. Или, если пофантазировать, то отказаться от текущей модели браузеров(процесс на страницу), и просто весь браузер собрать в безопасный wasm.

А лично я пока продолжаю считать, что отдельный процесс на плагин - наше все.

#maskray, #mold

Коллега никак не успокаивается(и это хорошо!), написал план про ускорение LLD.

https://discourse.llvm.org/t/parallel-input-file-parsing/60164

Речь идет про распараллеливание построения таблицы символов.

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

КМК, тут коллегам нужно уже перестать сцать менять форматы файлов, и подумать на предмет непарсируемых .o/.a файлов, например, используя flatbuffers, или capnproto.

Но, к сожалению, в мире дедов с ABI С/C++ это малореалистично.

https://matt-rickard.com/the-unreasonable-effectiveness-of-makefiles

https://lobste.rs/s/sq9h3p/unreasonable_effectiveness_makefiles

Тут вот коллега восторгается, как же хороши Makefile, и как же они классно умеют выполнять DAG.

"Does not manage the state itself. No database of file modification times, checksums, or build output files that could cause bad states to happen. Instead, make just compares the file modification times of the outputs to the inputs."

Знаете, мне это все кажется аргументацией в стиле "оно случилось именно так, потому что никак иначе случиться не могло". Слабый атропный принцип, да.

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

В доказательство предлагаю вам пофантазировать, как бы выглядел тулинг вокруг сборки, и выполнятор DAG, если бы авторы Unix сделали не только mtime, а какую-нить скользящую чексумму, доступную через вызов stat(), для каждого файла в системе.

А make - это просто тот выполнитель DAG, который мог быть сделан с помощью куцего posix api, без дополнительных усилий.

Он был неплох, для своего времени, и не более того.

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

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

Недавно вышли новые binutils. И, в связи с этим, у меня есть несколько не очень связанных тем, но про binutils!

1) "В утилиту nm добавлена опция "--no-weak" ("-W") для игнорирования weak-символов."

Казалось бы, мелочь, но. В данном случае компилятор и линкер от проекта GNU следует за проектом LLVM/Clang, причем они решили даже не коверкать название опции, как это было с -fcolor-diagnostics, а взяли ее as is. Я, конечно, считаю это очень важным, потому что проекту GNU я желаю или радикально поменяться, или уже загнуться.

2) Давно хотел рассказать про de-vendoring binutils, который я проделал.

binutils - это набор из 6 рекурсивных configure скриптов, которые вызывают друг друга, и собирают 3 бинаря да 2 библиотеки.

Это очень всрато, и я бы не стал это трогать, но:

* perf требует одну из этих "недокументированных" библиотек - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/perf/unwrap/ix.sh#L22 причем эта недокументированная библиотека не заботится об API, поэтому сломалась при обновлении - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/perf/unwrap/ix.sh#L61

* понадобилось дотащить нетривиальный параметр до одного из Makefile, в случае рекурсивных configure из коробки это не делается - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/ld/ix.sh#L24

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

Мои binutils - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/binutils/ix.sh Параллельность сборки так выше, чем у ad hoc запуска configure из configure.

3) А вы знали, что в проекте GNU есть две конкурирующих реализации ld/as/etc? Это elfutils, и binutils. Причем про binutils знают все, а вот про elfutils даже я узнал всего год назад, хотя, казалось бы, сколько лет с Linux.

Историю появления elfutils я пока не раскрутил, но там явно что-то интересное.

4) Одна из развендоренных библиотек называется libiberty. Вопрос - почему у нее такое странное название, и что оно означает?

https://www.phoronix.com/news/Glibc-2.36-EAC-Problems

Треш, угар, содомия.

#glibc нарушили базовое предположение про совместимость, что код, собранный со старой glibc на старом Linux, продолжит работать и на новых Linux. #abi

Очень забавно, как Миша крутится, как уж на сковородке, пытаясь представить это как fault от valve:

"DT_GNU_HASH has been around for a decade and a half and can lead to much faster linking and loading times. Most Linux distributions and open-source software have been happily using DT_GNU_HASH for years"

"Ну, все же уже 10 лет используют новый хеш" (ну а все остальные - ССЗБ, видимо)

"With Glibc 2.36, DT_HASH no longer gets set since they dropped "--hash-style=both" since the DT_GNU_HASH is superior, most systems should just be using that, and eliminating the DT_HASH section saves about 1% or 16kB of space for the Glibc shared object"

Серьезно? Сука, сэкономили 16 килобайт в .so?

"Now we'll see what happens with upstream GNU C Library developers around this or if they'll wait it out and punt the ball into Epic Games' court to switch from depending upon DT_HASH to the DT_GNU_HASH that has been widely used on Linux systems for over a decade"

Не, ну раз 10 лет все(?) уже успешно используют новую фичу, то те, кто использует старую - ССЗБ, и их, конечно, можно послать.

Авторы glibc - #errogant(e intended) красноглазые пенсионеры, ничего они не откатят:

https://sourceware.org/pipermail/libc-alpha/2022-August/141304.html

- The choice to have DT_HASH is with the distributions. If this breaks specific applications then those developers need to engage with the ecosystem or adapt their software.

Errogant, потому что они, на голубом глазу, заявляют, что не ломают ABI:

"We aren't breaking ABI when we remove the PLT, remove the old HASH, or other Linux ELF change"...

Нет слов.

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

В конце концов, где вам еще так зажигательно, и с огоньком, расскажут про binutils!

А, ну и специальное предложение для 1000-го пациента радиослушателя остается в силе!

Будни #bootstrap

Я тут непоправимо улучшил свою реализацию sudo.

Напомню, что sudo у меня сделан через ssh на localhost, с эскалацией привилегий до root. Это, в том числе, позволяет не иметь #suid бинарников в системе.

К сожалению, у этого решения был недостаток - он не сохранял current work dir. И, в целом, это правильно - зачем же на удаленном серваке ssh выставлять cwd в тот cwd, который у клиента?

Для этого я запилил простенькую программу, https://github.com/pg83/ix/blob/main/pkgs/bin/setcwd/cwd.c, которая выставляет cwd, и делает exec в свой аргумент. Наверняка что-то такое есть в #execline, но, напомню, ее автор - #errogant упырь. То же самое можно было бы накостылять на sh, но тогда пришлось бы заниматься нетривиальным escaping аргументов.

Ну и заюзал ее в своей обертке над ssh - https://github.com/pg83/ix/blob/main/pkgs/bin/sud/runit/ix.sh#L24

Обертка так же прокидывает TMPDIR, через стандартную утилиту env, потому что а где еще создавать временные файлы, кроме как в моем же сессионном TMPDIR?

Другие env переменные моя обертка не прокидывает, и, КМК, это хорошо.

https://blog.hiler.eu/win32-the-only-stable-abi/

Хорошее резюме про DT_HASH/DT_GNU_HASH.

Отрадно видеть, что не только я офигеваю от бесчинств glibc.

В процессе бутстрапа есть момент, когда нужно с помощью системного gcc собрать промежуточный clang, котрый уже соберет настоящий clang, которым можно собирать все остальное.

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

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

https://github.com/pg83/ix/blob/main/pkgs/bin/clang/14/gcc/ix.sh#L9 - вот, например, список исправлений, который нужен для clang-14, для gcc 7-12.

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

Лечится указанием auto вместо конкретного типа.

Причем, знаете, ошибка в одном каком-то файле на связку версий (gcc-clang), не то чтобы часто повторяется по коду(не нужно править в сотне мест).

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

Вряд ли это так, но с каждым новым clang у меня такое мнение растет и крепнет.

Собственно, мой вчерашний пост был, в том числе, про то, что я теперь умею инсталлироваться с любого "обыкновенного" дистрибутива, в котором есть хотя бы gcc >= 7, ну и python >= 3.9

Кстати, факт про версию питона был для меня довольно неожиданным, я, наверное, хочу поддержать и более ранние версии, чтобы уметь ставиться (хотя бы) с ubuntu 20. В ней, как ни странно, 3.8.

Вот это вот все мелочи, но каждой из них нужно уделить внимание, потому что в них лежит тонкая граница между "что это за говно, оно у меня даже не запустилось" и "какая классная вещь, дам ей шанс!"ю

TIL что case/esac if/fi в shell - это не оригинальное изобретение авторов shell, а пришло к нам из Algol 68.

https://www.cnews.ru/news/top/2022-08-12_otechestvennyj_ubijtsa_macbook

"Российский «убийца MacBook» на процессоре «Байкал» готов. Впервые показан финальный вариант дизайна"

Даже странно, что cnews, в кои-то веки, не соврал.

С учетом того, что топовые версии этого куска говна можно будет заказать с титановым корпусом, то им вполне можно будет расколошматить 10 - 20 macbook-ов.

Все же любят фоточки?

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

Вообще, в этой фотографии много истории и смысла.

Например, сервер я купил 3 года назад, и, по тем временам, это был очень крутой сервер(64 гига памяти, какой-то самый крутой не серверный Intel на тот момент, 36 весьма быстрых ядер, 3 nvme накопителя).

Купил я этот сервер по весьма странной причине - я хотел на нем гонять сборку и отдавать с него кеш для моей второй инкарнации дистрибутива Linux(напомню, что #stal/ix - третья).

Я уже пару раз делал подход к снаряду, сегодня расскажу еще пару деталей про второй заход.

Я тогда очень, очень торопился - мне казалось, что я уже точно знаю, что и как хочу сделать, и мне хотелось как можно скорее:

* запустить это все на голом железе

* отдать наружу

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

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

* я "сэкономил" много усилий на сборке сборочных систем, типа cmake, meson, и потом у меня их производные адово глючили.

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

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

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

Клавиатура, кстати, классная - клацает, как в детстве, и с подсветкой!

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

Ну и как еще одну тестовую площадку для #stal/ix, которая, кстати, встала на новую железку довольно буднично и просто(если не считать сборку ведра под новую конфигурацию).