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