Решил рассказать про второй способ описания закачки кастомных зависимостей.

Потому что звучит сложно, а на деле довольно интересно, ну и получилось неплохо.

Я разделил changeset на 3 части:

* Первая часть - очень грубо прорубить дорожку. https://git.sr.ht/~pg/ix/commit/1a08ffd42c9b82ac913bc85212b980af5542fa53 Тут, на самом деле, все очень просто - для сборочного таргета bin/emptty я завел еще один таргет, bin/emptty/src, который тупо на скачанную папку с github зовет go vendor, и потом прикапывает выхлоп в tgz файл - https://github.com/pg83/ix/commit/1a08ffd42c9b82ac913bc85212b980af5542fa53#diff-4f24bc72d343374a778107da01dbbdec4922ff6ece3064de9bebc53ffadd0a6dR17-R19 (важно отметить, какие я использовал опции для tgz, чтобы получить повторяемый результат). https://github.com/pg83/ix/commit/1a08ffd42c9b82ac913bc85212b980af5542fa53#diff-4f24bc72d343374a778107da01dbbdec4922ff6ece3064de9bebc53ffadd0a6dR23-R24 - в install просто копируем получившийся tgz в ${out} https://github.com/pg83/ix/commit/1a08ffd42c9b82ac913bc85212b980af5542fa53#diff-4f24bc72d343374a778107da01dbbdec4922ff6ece3064de9bebc53ffadd0a6dR32 - вот тут интересная "хитрость". Моя сборка пакетов предполагает, что блок fetch, если он есть, кладет исходники в ${src}, а если блока fetch нет - то он не выставляет эту переменную среды. Ну я и воспользовался этим фактом, теперь в bin/emptty нет блока fetch, но зато эту переменную среды выставит зависимый пакет, ровно туда, куда положит скачанный исходник, и все магически заработает "из коробки". https://github.com/pg83/ix/commit/1a08ffd42c9b82ac913bc85212b980af5542fa53#diff-ba13220bef6450320bd58efdcf2632da60599c28a7f84d477350711c6e7736bcR16 - флажочек для go build, чтобы он использовал завендоренные зависимости.

* Вторая часть марлезонского балета - https://github.com/pg83/ix/commit/a984214c3b43b36702da09a648a311530731e223 Очень простая идея - а давайте сделаем таргет на закачку исходников параметризуемым по урлу, в котором лежит seed для go vendor, чтобы не кажому проекту на go нужно было копипастить этот волшебный таргет на закачку, а просто воспользоваться готовым шаблоном - https://github.com/pg83/ix/commit/a984214c3b43b36702da09a648a311530731e223#diff-ba13220bef6450320bd58efdcf2632da60599c28a7f84d477350711c6e7736bcR6

* И третья часть - а давайте уберем всю эту некрасивую машинерию(указание флагов для таргета, дополнительные go build флаги) под капот нового шаблона сборки? https://github.com/pg83/ix/commit/0a42b0c0634c265278c90eed900e09f97483e1fc#diff-3f8ca95fe0cd560dcf72bdf4e6dfb833490fde8d741142c4300d61dc3f93c1c5R5

Собственно, "чистая" сборка go кода выглядит вот так - https://github.com/pg83/ix/blob/main/pkgs/bin/emptty/stock/ix.sh Отличие от предыдущего варианта - вместо блока fetch появилось два блока go_url + go_sum.

Пока не сделано:

* Возможность фиксации md5 для получившегося git.tgz

* Навести немного красоты, сейчас эта дополнительная зависимость типа bin(я ее подцепил просто как еще одну тулзу для сборки), а надо тип aux/data.

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

Девочка Антон познает #rust:

https://recursion.wtf/posts/rust_schemes/

Новый язык - это всегда хорошо, можно переизобретать одни и те же штуки в сотый раз, и оно снова будет к месту!

TL;DR - рекурсивный обход дерева в куче тормозит, давайте мы ноды положим в вектор, вместо указателей у нас будет индекс, и, чтобы это не выглядело всрато, накрутим поверх какого-то синтаксического сахара.

Я, как С++ программист с опытом, при чтении этой статьи испытал неиллюзорный butthurt:

* Почему бы не воспользоваться стандартным советом - "положи все это в memory pool, и не выебывайся"?

* По мне так страшный, но straightforward, код был понятнее, а вот ее перверсии с преобразованием кода я не понял от слова совсем, наверное, потому что пока плохо понимаю Rust.

После прочтения пошел гуглить про Rust memory pool, https://docs.rs/mempool/0.3.1/mempool/, увидел там красивое:

"Note that the pool returns an immutable reference. If you need a mutable reference, then use a RefCell. (Which is guaranteed safe by the pool.)"

Тут, меня, конечно, торкнуло задать наконец-то правильные вопросы:

* А как вообще Vec возвращает &mut? Он же должен вернуть нечто, что одолжит ссылку и на сам Vec? https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#2586-2593 Yep.

* А что такое RefCell? https://doc.rust-lang.org/src/core/cell.rs.html#947 Классная штука! Позволяет перенести проверку "максимум 1 мутабельная ссылка на объект" в runtime.

После этого знания, конечно, передо мной вновь замаячил вопрос "а нафига оно все это нужно", если в самых сложных и интересных случаях мы эту проверку таки перенесли в runtime(возможен panic при неверном использовании), и компилятор нам ничего не гарантирует.

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

К chromium я постепенно подбираюсь, вот, собрал nodejs, который, за каким-то хером, нужен для сборки хрома.

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

Вот, пожалуйста:

* https://wiki.gnome.org/Apps/Eolie, между прочим, тоже часть Gnome, так же как и epiphany. Вот у людей ресурсов, столько никому не нужных браузеров развивать? К сожалению, он написан на python.

* А вот еще один браузер на основе webkit, тоже с вертикальными вкладками - https://github.com/sonnyp/Tangram К сожалению, он написано на java script, причем, накакой-то очень всратой его разновидности - https://gitlab.gnome.org/GNOME/gjs Видимо, сейчас очень модно плодить JS рантаймы - https://deno.land/ - на Rust, https://bun.sh/ - на zig, да на любой вкус. Вот, гномовцы себе запилили на spidermonkey от Мозиллы, прекрасный выбор, что тут можно сказать.

Я стараюсь держаться подальше от скриптовых приложений для десктопа.

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

Ну его нахер, посижу еще на epiphany.

https://lwn.net/Articles/903033/

"On a personal note, the most interesting part here is that I did the release (and am writing this) on an arm64 laptop. It's something I've been waiting for for a _loong_ time, and it's finally reality, thanks to the Asahi team. We've had arm64 hardware around running Linux for a long time, but none of it has really been usable as a development platform until now.

It's the third time I'm using Apple hardware for Linux development - I did it many years ago for powerpc development on a ppc970 machine. And then a decade+ ago when the Macbook Air was the only real thin-and-lite around. And now as an arm64 platform."

Хренасе, Линус пользуется Asahi.

https://old.reddit.com/r/rust/comments/us328s/can_someone_from_the_rust_community_share_their/i91o4wj/

Забавный текст.

Коллега описывает проблемы C-style linking model, которая используется в дистрибутивах, для распространения С++/Rust/Go кода.

Причем описывает хорошо, со знанием дела, а вот выводы делает совершенно неверные.

Пишет, что надо при сборке пакетов через go/cargo/etc фиксировать список зависимостей, и при их изменении инициировать пересборку зависимостей.

Херь какая-то.

Правильно так - каждая версия каждого пакета привязывает к себе конкретный набор конкретных версий(без <=, >=), и для rebuild нужно поменять этот список, и апнуть версию пакета.

Что делать с security багфиксами?

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

Что делать, если пакет стал бесхозный, или владелец игнорирует баг?

* Форкните пакет, бампните версии, выложите в репозиторий.

* А вы точно хотите использовать такой код? Подыщите альтернативу.

* Можно вообще ничего не делать. Не понимаю этого безумия, когда надо пересобрать все, что зависит от zlib/openssl, когда там находят баг. Почти наверное, баг затрагивает мало кого.

Я в первой серии про #bootstrap рассказывал вот про этот вот проект - https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst

Их задача - полностью исключить машинногенерируемый(закоммиченный) код из процесса сборки, все нужно собрать исходя из ground truth. Ну, то есть, борются за то, чтобы исключить из сборки 10 configure скриптов по 10000 строк кода каждый(на bash).

Интересно, что они делают с ядром Linux:

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

"Добавлено более 420 тысяч строк кода, связанных с драйвером amdgpu, из которых около 400 тысяч строк приходится на автоматически сгенерированные заголовочные файлы с данными для регистров ASIC в драйвере для GPU AMD, а ещё 22.5 тысяч строк обеспечивают начальную реализацию поддержки AMD SoC21. Общий размер драйвера для GPU AMD превысил 4 млн строк кода".

Я так понимаю, что и там 2-4 миллиона строк кода - автоматически сгенерированные.

В принципе, AMD там может прикопать вообще все, что угодно. Интересно, почему оно не генерируется в процессе сборки.

В целом, я доделал вендоринг для #go.

Some highlights:

* Добавил в графогенератор возможность выставить факт того, что нода будет использовать сеть, и факто того, что нода будет производить файлы с заранее известными sha. https://git.sr.ht/~pg/ix/tree/main/item/pkgs/die/go/vendor.sh#L13-17

* Сделал так, что нода, которая хочет сеть, обязана выставить sha для своих output - https://git.sr.ht/~pg/ix/tree/main/item/core/gg.py#L48-49 Тем самым, я гарантирую "чистоту" выхлопа.

* Нода, которая сеть не заказала, сеть не получит - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/assemble/as.go#L196-199! (в сторону - мне прямо нравится писать на Go(ну, на моей модификации Go, я автор, я так вижу), надо про это написать отдельно)

* Я не очень понял, как правильно завендорить все проекты, находящиеся в одном дереве исходников за раз. Пока получилось как-то так - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/die/go/vendor.sh#L24-27, если знаете способ лучше - расскажите!

* Ну и немного магии с tar, https://git.sr.ht/~pg/ix/tree/main/item/pkgs/die/go/vendor.sh#L31, чтобы получить bit identical tar.gz файл. C bsdtar повторить пока не получилось, поэтому пока тут используется gnu tar.

Правило "хочешь unpure input, гарантируй pure output" мне очень нравится, с его помощью можно сделать несколько приятных штук, например, сделать так, чтобы нода, генерирующая сертификаты для всей системы, зависела только от sha своего output, а не от curl + openssl.

https://mort.coffee/home/tar/
https://www.opennet.ru/opennews/art.shtml?num=57587 #CVE

Я тут подумал, что было бы очень круто, если бы всякого рода распаковщики можно было запускать в своем mount namespace + chroot, ну, то есть, чтобы / был той папкой, куда мы распаковываем.

Например, вот так:

pg-> unshare -r -m sh
pg-> mkdir -p new_root/bin
pg-> cp /bin/* new_root/bin/
cp: omitting directory '/bin/bin_dhcpcd_sys'
cp: omitting directory '/bin/bin_ix'
cp: omitting directory '/bin/bin_openresolv'
pg-> chroot new_root /bin/sh
pg-> ls -la /
total 16
drwxr-xr-x    3 0  0 17 Aug  3 02:32 .
drwxr-xr-x    3 0  0 17 Aug  3 02:32 ..
drwxr-xr-x    2 0  0 12288 Aug  3 02:32 bin

(папочку bin я скопировал, чтобы внутри chroot можно было бы показать, где я)

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

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

https://theevilskeleton.gitlab.io/2022/07/28/libadwaita-fixing-usability-problems-on-the-linux-desktop.html

SJW текст, полный двоемыслия.

"GNOME developers typically use copyleft licenses, specifically GNU licenses like GPL. GPL prevents entities from creating proprietary and closed source forks. For example, if I fork (grab the code) a GNOME project that is licensed as GPL, I legally cannot modify and redistribute the software without disclosing the source code, because GPL prohibits forkers from doing so, thereby literally protecting user freedom."

"While “locking” down theming may worsen user freedom, it prevents distributions from breaking applications, as a result protecting user experience. Every decision taken has to have some compromises. GNOME developers are slightly compromising user freedom to protect user experience, as it prevents users from getting a subpar experience out of the box with GNOME applications. In my opinion, this is absolutely worth the compromise."

Два абзаца подряд, человек не понимает, что противоречит сам себе(IMHO).

Как в одной голове укладывается что "gpl это хорошо, потому что защищает свободу пользователя" и "ну, местами на эту свободу пофиг, главное - UX".

"In conclusion, theming is very sensitive to change, even at the slightest. While users knowingly theming applications were not a problem for GNOME developers, the problem lied in distributions shipping custom themes despite explicitly being asked not to."

"This is also a very important lesson to every one: having the freedom to do something doesn’t mean it should be done. While it is neat idea to be able to do whatever you want, there is a risk that you can affect people around you, or worse, yourself."

"Just because you can, doesn’t mean you should."

Я так понимаю, это про

"With these problems in mind, this lead to GNOME contributors to write an open letter in 2019, to politely ask distributions to stop shipping custom themes by default, and let users manually apply themes if they ever choose to do so. However, within a couple of years after the letter, nothing had changed: distributions continued to ship custom themes by default, which caused them to break many applications"

А это вообще прекрасно. Неэтично модифицировать код, когда тебя просят этого не делать!

Лицензия? Не, не слышали, зачем какая-то лицензия, если можно в какой-то момент заявить, что конкретное изменение в коде - плохо, и все тут?

Есть такой проект - http://www.oilshell.org/, https://github.com/oilshell/oil

Я на него регулярно наталкиваюсь, когда читаю "сегодняшний" список на version upgrade для моих пакетов.

Мне, конечно, очень интересно, что это такое, только я пока так и не сумел понять.

https://www.oilshell.org/cross-ref.html

У автора примерно 100500 неконсистентных идей, от текста к тексту разных:

https://www.oilshell.org/blog/2018/01/28.html

https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#more-ambitious-ideas

Шелл сначала был написан на Python, а потом его автора торкнуло, и он решил все ускорить в 100500 раз.

Нет чтобы переписать там на go, или на C++, он начал придумывать какую-то систему непрерывного "морфинга" кода с Python на С++, со своим runtime и GC:

http://www.oilshell.org/blog/2022/05/mycpp.html

http://www.oilshell.org/blog/2022/05/gc-heap.html

http://www.oilshell.org/blog/2022/03/middle-out.html

Там уже 3 каких-то разных языка:

https://www.oilshell.org/cross-ref.html?tag=osh-language#osh-language

https://www.oilshell.org/cross-ref.html?tag=oil-language#oil-language

https://www.oilshell.org/blog/2020/10/big-changes.html#appendix-the-tea-language

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

Короче, это написал или сумасшедший с биполяркой(очередной TempleOS?), или какой-то сумрачный гений, и я просто не могу его понять(или и то, и другое, вместе). Но откуда тогда 2к звезд на github?

RADARE CUMS WITH ABSOLUTELY NO WARRANTY

Будни #bootstrap #vendor

Собирал тут себе rizin. Не то что он мне очень нужен, как обычно, увидел в списках на обновление, и решил, что оно мне надо.

Хотел было коротенько написать, что сборка сделана очень по уму - поддержка статической сборки со всеми плагинами из коробки, релоцируемый бинарь, ну и de-#vendoring хорошо сделан.

Но черт меня потянул посмотреть, что же это вообще такое...

https://rizin.re/posts/faq/:

Помимо всякого bullshit про заведение code of conduct, я там наткнулся на прекрасное:

"We started efforts of cleaning the source code from offensive phrases and comments. In addition, we will put efforts in creating a more inclusive and diverse community and welcome new contributors"

Тут, конечно, запахло жареным.

На удивление годный топик на LOR про эту тему - https://www.linux.org.ru/news/development/16060831

Ну и на reddit неплохо - https://www.reddit.com/r/ReverseEngineering/comments/k996jq/rizin_fork_from_radare2/

TL;DR - часть команды устала от бесконечных подколок на гейско-анально-фекальную тематику, хехе.

Ссылка на fortunes, которые ранее выдавала radare2:

https://github.com/radareorg/radare2/pull/17980/files
https://github.com/radareorg/radare2/pull/17980/files#diff-00c5297b25daa28f9c6b47774991c52e3f599a89fa8b735f51e34c11e30d9821
https://github.com/radareorg/radare2/blob/a335247dacde918d027b776cea13bba20238de8c/doc/fortunes.nsfw

Nobody can hear your calls for help
There's someone under your bed awaiting

I like to suck nibbles and make hex.
ASLR stands for Age/Sex/Location/Reverser.
I script in C, because fuck you.
Don't masturbate at me
Do you want to see my internals? [Y/n]
The Security Glory Hole

А вот, например, как выглядят пути к файлам: https://github.com/radareorg/radare2/blob/master/libr/anal/flirt.c

Слушайте, ну мне тоже нравится гачимучи тематика(а кому не нравится? А видели, кстати, Херрингтона в ящике? https://medialeaks.ru/2806ndi-str-billy-herrington-fake/), поэтому, в целом, мне бы было норм, но я прекрасно понимаю, почему всяких неженок это может задеть, да.

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

"Компания GitLab планирует в сентябре внести изменения в правила использования сервиса, в соответствии с которыми проекты, размещаемые на хостинге GitLab.com бесплатно, будут автоматически удаляться, если в течение 12 месяцев их репозитории будут оставаться неактивными"

Какие бы я отсюда сделал выводы?

Как минимум, что компания gitlab не имеет глобального key-value стора, для хранения коммитов(для дедупликации). Потому что в нормальной модели(когда тебе не приходится материализовать git репозиторий на диске для работы с ним) форк не должен стоить почти ничего.

Особенно хорошо эта новость смотрится на фоне призыва к отказу от github - https://sfconservancy.org/blog/2022/jun/30/give-up-github-launch/

#vendoring #vendor #npm

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

В копилочку темы про пользу дистрибутивов и их мейнтейнеров.

#openssl, конечно, кусок говна.

Вот bsdtar, слинкованный с nettle(или mbedtls, там столько же):
-r-xr-xr-x 1 ix 1000 3792552 Aug 5 11:55 /ix/store/PTsFUUKyVXAHASCY-bin-bsdtar/bin/bsdtar

А вот с openssl:
-r-xr-xr-x 1 ix 1000 6849040 Aug 5 15:07 /ix/store/YJVZIQjBFUSJ4XX3-bin-bsdtar/bin/bsdtar

Причем я проверил, что с mbedtls и nettle никаких опций, по сравнению с openssl, не выключено.

Наверное, с openssl приехала какая-нибудь фабрика, которая влинковала в себя весь код openssl.

К сожалению, openssl - это common denominator, почти весь код поддерживает или openssl, или еще что-нибудь, и вот это что-нибудь - всегда разное.

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

(кроме довольно редких случаев по типу bsdtar)

Кстати, обратил внимание, что там, где я делаю выбор в пользу openssl, Arch часто делает выбор в пользу gnutls. Интересно, это совпадение, или у них есть какая-то политика на этот счет?

Тут вот на реддите обсуждают новый-кленовый компилятор питона.

https://www.reddit.com/r/Python/comments/w7vlim/i_made_a_python_compiler_that_can_compile_python/

https://github.com/Omyyyy/pycom/tree/main

Окинул это взглядом, что имею сказать:

* https://github.com/Omyyyy/pycom/blob/main/src/pycom/compiler.py - по сути, это жалкая пародия на cython, выигрыш за счет выноса control flow в сишечку.

* Из питона поддерживается всего ничего, код "a = 1; a = 'x'" никогда с таким подходом работать не будет.

Короче, какая-то пионерская поделка, но, блин, 1К звезд на гитхабе! 1К, Карл!

У реально работающего cython - 7K. https://github.com/cython/cython

Куда катится мир?

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

Две новости про шифрование, хорошо идут вместе.

Я, конечно, считаю всю эту тему хайпом и отмывом исследовательских бабосов, потому что:

* Реальное железо, которому это будет релевантно, появится не при моей жизни.

* КМК, пространство алгоритмов в этой области исследовано так себе, и совершенно непонятно, почему вот такое фиаско не случится снова.

Обновлял libwebp, минорная версия.

Судя по всему, webp начала зависеть от библиотеки с тредами, или эту зависимость просто явно прописали, или случилась какая-то дичь, это же #cmake.

Это не то чтобы очень важно, но в экспортных cmake файлах появилась вот такая запись:

"set_target_properties(WebP::webp PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include;${_IMPORT_PREFIX}/include"
INTERFACE_LINK_LIBRARIES "Threads::Threads"
)"

Не то чтобы это должно было быть хоть сколько-то важно, но это сломало сборку QT, каким-то нетривиальным образом:

"- Found OpenSSL: /ix/store/3YPdIxQVL9oMNgXL-lib-openssl-3/lib/libcrypto.a (found version "3.0.3")
-- Found WrapOpenSSLHeaders: /ix/store/3YPdIxQVL9oMNgXL-lib-openssl-3/include (found version "3.0.3")
CMake Error at /ix/store/BSYeU5Bd9S8IYSLe-lib-qt-6-base/lib/cmake/Qt6/QtPublicTargetHelpers.cmake:257 (set_property):
Attempt to promote imported target "Threads::Threads" to global scope (by
setting IMPORTED_GLOBAL) which is not built in this directory.
Call Stack (most recent call first):
/ix/store/BSYeU5Bd9S8IYSLe-lib-qt-6-base/lib/cmake/Qt6/QtPublicWalkLibsHelpers.cmake:252 (__qt_internal_promote_target_to_global)
/ix/store/BSYeU5Bd9S8IYSLe-lib-qt-6-base/lib/cmake/Qt6/QtPublicWalkLibsHelpers.cmake:225 (__qt_internal_walk_libs)
/ix/store/BSYeU5Bd9S8IYSLe-lib-qt-6-base/lib/cmake/Qt6/QtFindPackageHelpers.cmake:12 (__qt_internal_walk_libs)
/ix/store/BSYeU5Bd9S8IYSLe-lib-qt-6-base/lib/cmake/Qt6/QtFindPackageHelpers.cmake:181 (qt_find_package_promote_targets_to_global_scope)
src/imageformats/configure.cmake:19 (qt_find_package)
src/plugins/imageformats/CMakeLists.txt:9 (include)"

cmake - это треш, угар, и содомия, а сборочные скрипты QT для cmake - это треш в квадрате.

Что значит это сообщение об ошибке, я не понял, починил по рабоче-крестьянски: https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/webp/ix.sh#L17-19

Кстати, с cmake сборка webp и так не сильно дружила, экспортные файлы она клала куда-то не туда: https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/webp/ix.sh#L14-16

#vendoring #vendor

А иногда люди очень смешно(нет) косячат, когда занимаются ручным(без автоматизации) вендорингом(а в мире С/С++ по другому и не бывает).

Вот, например, автор mold предусмотрел использование некоторых библиотек из системы, типа xxhash, и я этим воспользовался - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/mold/ix.sh#L25

Но, что самое интересное, даже с выставленным этим флажком он продолжает брать заголовок xxhash.h у себя, а не из системы, при этом inline часть xxhash получается его версии, а non-inline - из системы.

Как я это понял?

Я стараюсь при де-вендоринге удалять проблемный код - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/mold/ix.sh#L36

Ну и дальше сборка попала на то, что не могла найти заголовок - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/mold/ix.sh#L43, в системе он не по тому пути лежит.

В случае xxhash это не очень-то и страшно, потому что оно почти целиком inline, а вот в случаях, когда код размазан между заголовком и .c файлом такое может доставить прилично хлопот.

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

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

* Пытается пропихнуть свою вполне обыкновенную шину в ядро, аргументируя это несуществующими преимуществами в 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 - методологически некорректно, предложенное измерение этого не показывает.