https://www.opennet.ru/opennews/art.shtml?num=61768
https://marc.info/?l=openbsd-cvs&m=172443408727088&w=2

"With this commit, we have completed an amusing mission of
replacing the final parts of the original OpenBSD"

"We have reached OpenBSD of Theseus"

Обиженка Тео вскрылся, и написал про истинную причину появления OpenBSD.

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

Не прошло и 30 лет, кстати говоря. Совершенно потрясающее упорство у человека.

Из opentofu удалили провайдеры для Rustack, SberCloud (ныне это cloud.ru) и Yandex Cloud.

remove some providers due to a new policy
https://github.com/opentofu/registry/pull/817

https://github.com/opentofu/opentofu/blob/main/README.md#registry-access
https://github.com/opentofu/opentofu/blob/main/TSC_SUMMARY.md#sanctions-russia-vs-registry-access

Собираются блокировать свои registry

https://github.com/opentofu/registry/pull/824

и продолжение

Fake situation. Fake Anton.

Как вы знаете, я всячески люблю пробовать новые #monospace шрифты, да и вообще, тема шрифтов #font (как самих шрифтов, так и их растеризации, и лукапа #fontconfig) мне интересна, заметки на эти темы появляются довольно регулярно.

(мои любимые моноширинные шрифты последние лет 10 - это Input Mono https://xn--r1a.website/itpgchannel/123, и Consolas, я их регулярно ротирую. Если вы хотите изменений в жизни - поменяйте шрифт, а еще можно переставить мебель)

Внезапно обнаружилось, что я пропустил замечательный шрифт от MS, https://github.com/microsoft/cascadia-code

Выяснилось это через заметку от Миши с фороникса https://www.phoronix.com/news/Microsoft-Cascadia-Next

Довольно неплохой шрифт, решил попробовать пожить с ним пару недель, потом напишу про результат.

https://gamengen.github.io/

Смотрите, какая красота - можно предсказать N+1 кадр игры, зная предыдущие, и user input. То есть, движок не нужен, такие дела!

В продолжение https://xn--r1a.website/itpgchannel/2157

https://jonathancarter.org/2024/08/29/orphaning-bcachefs-tools-in-debian/

Смотрите, какая красота.

Из debian удаляют bcachefs-tools, потому что:

"As it stands now, bcachefs-tools is impossible to maintain in Debian stable" как обычно, растаманы хотят самых свежий версий зависимостей, и это невозможно в таком консервативном дистрибутиве, как Debian. Строить херобору ("расслаблять" версии) автор пакета не захотел.

Ну и второе:

"With this in mind (not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit), I decided to remove bcachefs-tools from Debian completely"

Видимо, #Kent срет не только в kernel community, но и вообще там, куда дотянется.

#cpp #meme

слушайте, ну это должно было случиться в этом треде

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.

Это как так?