#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

https://github.com/serde-rs/serde/pull/2590 #blob

Из serde таки удалили бинарный блоб. Это, конечно, хорошо. Потому что скорость сборки - скоростью сборки, но она не должна достигаться таким вот хаком.

Меня больше, чем вся эта история с бинарным блобом, заинтересовала вот эта вот папочка - https://github.com/serde-rs/serde/tree/bfcd44704f847ac5a9f3072e102e803b5ebbef31/precompiled/proc-macro2 (ее уже нет в транке, потому что выпилили всю precompiled/ историю).

Я вот как в этом вот анекдоте:

- Василий Иваныч, сколько будет ноль целых пять десятых плюс одна вторая?
- Нутром чую, что литр, а доказать не могу!..

Нутром чую, что в этой папочке лежит реализация proc_macro, которая не требует загрузки .so в rustc, а работает через subprocess. Ну или я тогда не понимаю смысл этого precompiled binary - что там лежало-то?

Раскопки приводят к https://github.com/dtolnay/watt (от того же автора):

"Watt is a runtime for executing Rust procedural macros compiled as WebAssembly"

Короче, в конце тоннеля забрезжил свет, возможно, у меня получится прикрутить эту штуку к Rust, чтобы она использовалась вместо реализации по умолчанию, и не требовала загрузки свежесобранной .so в rustc. То, что там #wasm - это дело десятое, главное, что в виде отдельного бинаря.

#WASM #WebAssembly #WASI #blob #wazero

Тема с компиляцией C/Rust кода в wasm (https://t.iss.one/itpgchannel/1553), и использование его через wazero в go, кажется, пошла в массы:

https://github.com/ncruces/go-sqlite3

Очень разумный способ использовать зависимости на С/Rust без CGO, и без соответствующих проблем.

Правда, так как в go отсутствует вменяемая система сборки, sqlite3, собранный в wasm, прикопали прямо в репке - https://github.com/ncruces/go-sqlite3/blob/main/embed/sqlite3.wasm. Как я это нашел? Ну, так как я знаю, что go build не в состоянии выразить такую зависимость, то просто взял, и нашел.

Ай-яй-яй, никогда такого не было (https://t.iss.one/itpgchannel/1281), и вот, опять, нам тащат вирусню в проект добавили очередной supply chain attack.

#WASM #WebAssembly #WASI #blob

https://github.com/wasilibs/go-yamllint

Технология движется семимильными шагами!

На этот раз yamllint, запускается через тот же #wazero, только это не Rust, а вполне себе настоящий интерпретатор питона, собранный под #WASI.

(спасибо нашим читателям за наводку!)

Будни #bootstrap, #rant

Обновлял rqbit.

Это который упаковывает кучу js кода себе в бинарь, и вызывает для этого npm - https://t.iss.one/itpgchannel/2410

Обновление упало с ошибкой - https://gist.github.com/pg83/cd1ec54f5a4fd4f2e5cfc4b82e063c12

TL;DR - при обновлении приехал новый https://vite.dev/, который притащил за собой новый https://github.com/rollup/rollup (не спрашивайте, это говно бандлит JS код в 1 файл), который переписали на "мамой-клянусь memory safe" языке (https://github.com/rollup/rollup/tree/master/rust), а чтобы не портить пользователям малину, положили в пакет предкомпилированные даже не бинари, а .so для nodejs.

Вона там их сколько, даже для loongson есть:

https://github.com/rollup/rollup/blob/master/package.json#L19-L37

(для #stal/ix нет, ага)

Да, да, никогда такого не было, и вот, опять, зумеры подложили очередную вирусню в репу очередной supply chain attack:

#blob

https://t.iss.one/itpgchannel/1281
https://t.iss.one/itpgchannel/1301
https://t.iss.one/itpgchannel/2264
https://t.iss.one/itpgchannel/2084
https://t.iss.one/itpgchannel/1789
https://t.iss.one/itpgchannel/535

Что я сделал?

Даунгрейднул все эти зависимости, и все заработало:

https://github.com/pg83/ix/blob/main/pkgs/bin/rqbit/ix.sh#L22-L23

Что я буду делать, когда оно перестанет так собираться?

Стану проституткой!

Не знаю, изучу JS, наушники с котоушками у меня уже есть https://t.iss.one/itpgchannel/2444.

Будни #bootstrap #blob

Оказалось, что там есть версия rollup, которая собрана в бинарь, но под #wasm, и потому может быть исполнена на любом хосте с nodejs.

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

Заодно выяснилось, что там прикопан бинарник от https://github.com/evanw/esbuild, а это уже серьезнее, потому что он на go, статически слинкован, и я даже не заметил, что он у меня запускался в процессе сборки.

Изящно заменил его на свой - https://github.com/pg83/ix/blob/main/pkgs/bin/rqbit/ix.sh#L47-L52

Мораль?

Решил инвестировать больше времени в автоматическое выбрасывание из скачанных исходников всякого бинарного треша!