Я в первой серии про #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 - методологически некорректно, предложенное измерение этого не показывает.

Медленно продираюсь через сборку 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.

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