https://xn--r1a.website/tech_b0lt_Genona/4632

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

Мне это, конечно, напоминает мой "quest for statically linked linux", а как же. Ну, по модулю того, что я за статической линковкой, все же, вижу какой-то, вполне понятный, практический смысл.

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

В общем, мне стало интересно, что там такого в сборке bcachefs-tools, что господа из Debian не захотели ей заниматься, и я решил эту тулзовину собрать сам.

Сложность ее сборки в том, что там, на самом деле, сопряжено две ситемы сборки, одна для C-кода, на Makefile, вторая - для rust кода, через cargo.

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

Я это дело развернул так:

* Сначала собрал libbcachefs.a, отдельным сборочным таргетом https://github.com/pg83/ix/blob/main/pkgs/lib/bcache/fs/ix.sh

* Потом запустил сборку rust части, через свой обычный шаблок для сборки cargo проектов, ожидая, что libbcachefs.a доступна для линкера https://github.com/pg83/ix/blob/main/pkgs/bin/bcache/fs/tools/ix.sh#L16

К сожалению, все оказалось не так просто, но тут вина уже не товарища #Kent, а сумасшедших упырей, которые погромировали растовый bindgen.

Как обычно, все из-за желания сделать так, чтобы С/С++/Clang как будто бы и рядом не стояли, но С/С++ код хоть "как-то" бы обрабатывался.

Авторы #bindgen решили, что они будут загружать libclang.so на лету, динамически - https://github.com/rust-lang/rust-bindgen/blob/ae6817256ac557981906e93a1f866349db85053e/bindgen/Cargo.toml#L44-L47

А авторы крейта lang-sys/dynamic решили, что они не прото позовут dlopen("libclang.so"), а максимально обмажут этот процесс каким-то невнятным говном по "валидации" загружаемой .so - https://github.com/KyleMayes/clang-sys/blob/master/build/dynamic.rs Это, блядь, вообще что такое? Захера это поделие парсит ELF header? Какое его вообще дело, что лежит в libclang.so, когда dlopen() на нее сработает? Очередной выверт из серии "потому что можем".

Мне это важно, потому что у меня же нет динамичекой линковки, libclang.so вообще может быть не материализовано на fs, а вот dlopen "магически" сработает.

Но нет, нужно понавставлять палок в колес, лишь бы добавить ведро "безопастности".

К счастью, оказалось, что можно, довольно несложно, переключить bindgen на режим статлинковки с libclang - https://github.com/pg83/ix/blob/main/pkgs/bin/bcache/fs/tools/ix.sh#L25-L29 . Как это сделать нормально, с помощью cargo, я так и не понял. Это вообще возможно - переопределить через command line опцию для одной из зависимостей?

В общем, оно собралось, и вроде, даже работает, но осадочек от очередного взаимодействия с миром rust, остался.

Если бы не эти пляски с bindgen, то, в целом, я бы охарактеризовал этот пакет как довольно простой для опакечивания.

Мне тут напоминают, что нас уже больше 2000!

Заодно я решил напомнить, что у канала есть флудилка, там можно обсудить мои тексты, и просто пообщаться на разные темы - https://xn--r1a.website/it_pg_talks

Тут вот история про #http3 (я, кстати, офигел, что ее начало - это 22 год, а моему блогу, получается, уже 3 года) получила свое продолжение.

В какой-то момент времени openssl от MS (https://github.com/quictls/openssl) застрял на отметке 3.1, и дальше они перестали его ребейзить на новые версии openssl.

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

https://github.com/quictls/openssl/issues/138

Что с этим делать - непонятно, и процесс обновления "встал".

Поэтому, в какой-то момент, мне пришлось отказаться от использования этого форка, как основного, благо, в curl появилась поддержка #http3 через связку openssl3 + nghttp3. А раньше, напомню, работало только через связку ngtcp2 + http3, или через msquic, и оба этих варианта требовали патченого openssl.

От форка я успешно отказался (https://github.com/pg83/ix/commit/b6e7958e5d75115289c5960d74fdade419c41ca6), и теперь у меня есть ажно три способа сходить по http3:

* связка openssl-quic + nghttp3
* quictls (патченый openssl) + ngtcp2 + nghttp3
* quictls + msquic + msh3 (такой враппер над msquic)

Насколько они хорошо понимают друг друга - в следующей серии!

А вот коллегам из MS я бы порекомендовал или перейти на стандартный openssl в msquic, или начать шевелиться, и продолжить бекпортить новые версии openssl, а то народ (кажется, это nodejs, и у них из-за отставания версий уже проблемы - https://github.com/quictls/openssl/issues/138#issuecomment-1798639569) не поймет.

PR у них, кстати, висит с мая - https://github.com/quictls/openssl/pull/159

#нам_пишут, #безопастный_rust

https://github.com/DoumanAsh/xxhash-rust/issues/29#issuecomment-1691828171

Обещал написать, что там по #http3, так сказать, в поле.

Я взял 3 реализации HTTP/3, от openssl (далее O), от nginx (далее N), и от MS (далее M).

Я взял несколько сайтов, про кототорые достоверно, что они отдаются через HTTP/3. При этом, надо сказать, что я не нашел такой сайт от MS, с msquic, далее будет понятно, почему.

Плюс к этим сайтам, я взял cloudflare, про который достоверно известно, что они используют свою реализацию HTTP/3 (quiche, у меня ее нет), и я взял google, про который достоверно известно, что у них тоже своя реализация.

Тестировал такой командой:

curl -vvv -k --http3 https://host

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

https://cloudflare-quic.com/

O: HTTP/2
N: HTTP/2
M: HTTP/2

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

https://quic.nginx.org

O: HTTP/3
N: HTTP/3
M: HTTP/2

https://google.com

O: HTTP/3
N: HTTP/3
M: HTTP/2

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

Отдельно добавлю про клиент от MS (который у меня M, msquic) - он нигде не смог показать факт того, что умеет в HTTP/3. А еще на паре сайтов (например, github.com) выдал такое - curl: (16) Error in the HTTP2 framing layer, и не смог их скачать.

Я полагаю, именно в этом причина того, что MS убрали тестилку с ним, потому что реализация - говно, на нее забили хуй, и использовать ее не надо. Ну или ее плохо интегрировали в curl, но, все равно, HTTP/3 оно не смогло показать нигде.

Для проформы я посмотрел, что же там на https://microsoft.com:

O: HTTP/1
N: HTTP/1
M: HTTP/1

Что это значит? Что и серверная часть msquic - какое-то говно, ну или MS забили на нее, а использовать что-то другое не позволяет гордость.

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

И отдельный вывод про MS - MS хорошо делает мышки и шрифты, а все остальное у них - ну такое себе.

Оттепель

Проект пока не проект

Проект закона обязывающий блогеров с аудиторией больше 10 000 подписчиков подавать информацию о себе в Роскомнадзор
https://regulation.gov.ru/Regulation/Npa/PublicView?npaID=150487

https://github.com/mozilla/standards-positions/pull/1064

Неожиданный поворот в истории #jpeg_xl

Неожиданный не потому, что firefox хочет заполучить декодер формата на Rust, это как раз очень понятно (кодеки, вообще говоря, как раз очень подходят для того, чтобы их писали на Rust), а потому что

"To address this concern, the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox"

То есть, Гагл одной рукой удаляет поддержку #jpeg_xl из Chrome, а другой - пишет декодер на Rust, да еще и готов сам интегрировать его в Firefox.

Это как так?

Dear #Ladybird.

Как обычно, читал release notes #imgui, https://github.com/ocornut/imgui/releases/tag/v1.91.1, наткнулся на прекрасное:

https://codeberg.org/ronak69/dear-ladybird

Это такой web совместимый браузер, поверх движка #ladybird, и с gui на imgui.

Лайтовый движок, лайтовый gui, что может быть лучше?

Нам тут пишут, что systemd собрали с musl.

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

Неожиданно, что эта новость привлекла какое-то внимание, потому что systemd с musl собирали уже несколько раз, и, например, даже я это как-то сделал, в рамках #stal/ix. Ничего особо сложного в этом не было.

Я сделал даже больше, я его собрал в статически слинкованном виде!

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

Ну и, в целом, мне бы хотелось, чтобы в мире Linux было какое-то разнообразие, и тот же Alpine на systemd не заглядывался, потому что так оно здоровЕе.

https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-2024/

Оказывается, автор curl недавно писал примерно на эту же тему, и про проблемы msh/msquic тоже рассказывал.

Из текста я выяснил, что в debian поддержка #http3 реализована через связку gnutls + ngtcp2 + nghttp3, и я переделал так же, потому что пользовательская база у них пока чуть больше.

https://curl.se/mail/distros-2024-06/0000.html

"HTTP3 support was achieved by switching the curl binary to use the GNUTLS backend, but we still provide an OpenSSL libcurl"

Конфликт между старыми разработчиками ядра, которые пишут на C, и новыми, кто хочет в Rust, разгоратеся прямо сильно.

https://lkml.org/lkml/2024/8/28/1532

https://sporks.space/2024/09/05/is-linux-collapsing-under-its-own-weight-on-rust-for-linux/

https://vt.social/@lina/113045455229442533

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

https://www.youtube.com/watch?t=1529&v=WiPp9YEBV0Q&feature=youtu.be&themeRefresh=1

Конфликт, в целом, имеет очень понятную природу - разработчикам Rust нужны врапперы над абстракциями ядра, но:

1) эти абстракции плохо подходят для модели безопасности Rust, и старослужащие не хотят их менять в угоду Rust. Это плохо, я тут на стороне разработчиков Rust.

2) старослужащие хотят менять интерфейсы, и не учить новый язык. То есть, не хотят править абстракции Rust, когда меняют свои интерфейсы. Это, благодаря всратой модели взаимодействия Rust с внешним миром (когда надо руками захардкодить структуры и смещения в них), работает плохо. Тут я на стороне господ старослужащих, потому что надо взять, да сделать норм interop с C, и это задача для разработчиков Rust.

Вот тут (https://vt.social/@lina/113045455229442533) вот подняли интересную тему, что таки надо С++, а не Rust, потому что нормальный interop, нет ебли с lifetime, и вообще, это больше похоже на инкрементальное изменение, которое будет поддержано бОльшим числом мейнтейнеров.

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

Всемогущие мейнтейнеры, которые не разговаривают друг с другом, и делать что-то cross subsystems не представляется возможным, такие дела.

Рубрика "нам пишут".

https://github.com/the-benchmarker/web-frameworks/issues/1129

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

У проекта, между прочим, 25к звезд на гитхабе.

Гриш, ты не поймёшь в силу ограничений естественного интеллекта, но я для остальных попробую объяснить.

В армии нет никаких 1-1.
В ВУЗах нет 1-1.
На заводах нет 1-1.
У врачей нет 1-1.
У прораба с Джамшутом нет 1-1.

При этом заводы работают, образование люди получают, дома строятся, самолёты летают, банкоматы работают. Как же так?

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

И только в айтишке все в попу целованные. Не могут работать без тыквенного пряного латте и ван-ту-ванов с поцелуями.
#сракигорят

Шок-контент: гнумера забанили в wayland-protocols

Начал падать git clone, вот с такой вот ошибкой: https://gist.github.com/pg83/d332bbf2302234e793b8c487fe01633d

HTTP/1.1 работает. bisect-ом ничего не нашел.

Что это? Случайная ошибка? Или начало конца?...