Сегодня ссылочный блог, звиняйте.

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

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

В современном мире компания, которая делает браузер в качестве основного продукта, не жилец.

Впрочем, я не верю и про нишу, с их дурацкой лицензией на код и качеством самого кода.

———
https://lkml.org/lkml/2022/3/17/964

Rust в Linux, v5. #linux_kernel_rust

Честно, я с огромным удовольствием слежу за этой историей. Линус хранит гробовое молчание, и, я думаю, ему этот Rust как кость в горле.

Но сейчас Линус уже старый и сытый, и не хочет кусать руку, которая его кормит, поэтому послать в жопу то, что не осилил понять(речь про С++ и Rust, а я смею заверить, что критика тогдашним, молодым, Линусом, C++ - ну так себе) уже не выйдет.

Поэтому я получу огромное удовольствие, когда он прогнется, и сдастся. Ну или еще большее удовольствие, если нет, наблюдая за последствиями.

Вот такой вот я злобный и злопамятный С++ программист.

Божечки-божечки-божечки, НАЧАЛОСЬ! #linux_kernel_rust

https://lwn.net/ml/rust-for-linux/CAHkG_ewRo5uPOue3ZMAAPAc+eP7MNNU5iVym-JVG1jN7HD+XMg@mail.gmail.com/
https://lwn.net/ml/rust-for-linux/CAKfU0DLS5icaFn0Mve6+y9Tn1vL+eLKqfquvXbX4oCpYH+VapQ@mail.gmail.com/

Какие-то школьники интересуются, когда можно будет использовать crates.io и cargo в разработке Linux. С патчами про Rust все было и так понятно, но надо же иметь хоть немного совести, и подождать, пока поддержка Rust попадет в mainline.

Парсера json им не хватает в ведре, да.

———
https://github.com/microsoft/mimalloc/issues/574

Нашел багу в свежем mimalloc. Как? Очень просто, пересобрал с ним мир, и увидел в логах красивое:

pg-> /mix/store/mAZUHwYPOIGAPJOH-bin
    -coreutils-9-0/bin/sort 
sort: memory exhausted

gnu sort начал так ругаться на пустом вводе.

Стандартов на эту функцию нет, кто формально виноват, непонятно, но есть мнение, что reallocarray(a, n, m) == realloc(a, n * m) для всех n, m, которые можно безопасно перемножить.

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

———
https://github.com/WebPlatformForEmbedded/libwpe/commit/064bd78c534d18f9422ddbfe4ca762a42290531c

#igalia lia никак не уймется, и они запилили для WebKit еще один порт, для embedded. Он устроен хитро - есть loader, libwpe, который загружает конкретную имплементацию, которая уже и реализует настройку графического контекста для рендеринга. И есть конкретная референсная реализация для freedesktop проектов, wpe-fdo.

Сделано это всрато:

* loader зависит от libxkbcommon, то есть, наружу протекла абстракция ввода-вывода(от конкретной реализации)

* абстракция, насколько я понял, абстрагирует не только графику, но и звук. Через что они гоняют звук, я пока не понял, как бы не через wayland :D

На днях коллеги из Igalia решили, что, раз уж есть всего одна реализация плагина, то можно ее и не через dlopen открывать. Кстати, придумали элегантное(без шуток) решение - статический loader просто содержит в себе extern на символ из плагина, после чего с ним можно линковаться, как с обычной .so

https://github.com/WebPlatformForEmbedded/libwpe/blob/master/src/loader-static.c#L32

А теперь то же самое, в конкретном плагине:

https://github.com/Igalia/WPEBackend-fdo/blob/master/src/fdo.cpp#L33

Мне понадобился gdb, чтобы найти тут ошибку.

Очевидно, что этот статический loader никто никогда в реальной жизни даже не запускал. Я этим пидарасам так и написал - https://github.com/WebPlatformForEmbedded/libwpe/commit/064bd78c534d18f9422ddbfe4ca762a42290531c#r71375192

Вот моя реализация: https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/wpe/loader/loader.c