Мне тут напоминают, что нас уже больше 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-ом ничего не нашел.

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

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

"собрали опенсурс и продают"

На самом деле, хорошая новость, несмотря на то, что с запашком, если вы понимаете, о чем я.

Здоровое государство - естественный потребитель open source софта, и не должно тратить деньги на проприетарные решения, по возможности.

Помните план США и TSMC по строительству завода в Аризоне?

В одном из чатов по ПЛИСам наткнулся на крутую статью "TSMC’s debacle in the American desert" от 23-го апреля.

Крайне рекомендую ознакомиться.

В статье описываются трудности, с которыми столкнулись американские инженеры во время стажировки на тайваньском заводе Fab 18, где они пытались адаптироваться к местной рабочей культуре.

В частности, они столкнулись с проблемами, вызванными языковым барьером и различиями в подходах к работе: тайваньские инженеры привыкли работать по 12 часов в день, тогда как их американские коллеги предпочитали более сбалансированный рабочий график.

Кроме того американские сотрудники столкнулись с серьёзными проблемами из-за языковых барьеров. Почти всё общение на заводе, включая обучение и собрания, велось на тайваньском или китайском языках, что затрудняло понимание задач.
В теории, будущие тайваньские сотрудники Аризонского завода должны были помогать американским коллегам с переводом, но на практике у многих не хватало времени или опыта для этого.
В результате американские инженеры были вынуждены полагаться на Google Translate и программы для распознавания рукописного текста, которые часто давали неудовлетворительные результаты.

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

Как итог — некоторые американские инженеры начали искать новые карьерные предложения в компаниях с менее жесткими требованиями и лучшими карьерными перспективами. В статье также упоминается, что один инженер, работавший как в Intel, так и в TSMC, рассказал, что его тайваньские коллеги интересовались вакансиями в Intel, где они надеялись на лучший баланс между работой и личной жизнью.