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

Вот, пожалуйста, код, который должен прочесть конфигурацию шрифтов на машине, и найти все доступные шрифты:

https://github.com/RazrFalcon/fontdb/blob/master/src/lib.rs#L489

Самая основная проблема в этом коде - это то, что он не использует системный способ поиска шрифтов #fontconfig, а реализует все с нуля:

* Библиотека, которая умеет читать fonts.conf, и "сливать" несколько таких файлов в один. Правила fontconfig - сложные, библиотека реализует их весьма условно.

* Библиотека не линкуется с системным fontconfig, а содержит набор эвристик, поэтому вот этот вызов ведет в никуда - https://github.com/RazrFalcon/fontdb/blob/master/src/lib.rs#L492. Поэтому, когда этот код запускается у меня, он не может найти мой fonts.conf, и, соответственно, не видит мои настройки шрифтов, и пути поиска шрифтов.

* Там есть какой-то набор эвристик (который, очевидно, не совпадает с тем, что есть в #fontconfig), https://github.com/RazrFalcon/fontdb/blob/master/src/lib.rs#L498-L518, который у меня тоже не срабатывает.

* Авторы библиотеки (и fontdb, и fontconfig_parser) очевидно, не читали исходники fontconfig, и стандарты freedesktopp.org, либо реализовали все "спустя рукава". Потому что ни та, ни другая, библиотеки, не реализуют поиск доступных шрифтов (и конфигураций) в XDG_DATA_DIRS (это такой PATH для share/* файлов). Например, вот тут https://github.com/RazrFalcon/fontdb/blob/master/src/lib.rs#L547 надо пройтись по всем $XDG_DATA_DIRS/share/fonts тоже. Системный fontconfig это делает (https://gist.github.com/pg83/160815167eba28b9380a40079ae88a40), а эта пионерская поделка - нет (она пропускает все, что у меня лежит в /ix/realm/pg, из https://gist.github.com/pg83/160815167eba28b9380a40079ae88a40, потому что эта папка добавляется через XDG_DATA_DIRS).

Я, понятное дело, это все как-то закостылял, но, конечно, состояние этого кода оставляет самое удручающее впечатление.

#ladybird

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

Проекту всего ничего, а он продолжает нас радовать и веселить!

На этот раз его автор отжег тем, что сказал, что далее Ladybird будут пилить на Swift. Очень, очень (без сарказма!) хороший выбор для GUI приложения, наверное, даже лучше, чем С++ сейчас.

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

Отдельно стоит упомянуть аргументацию "а почему не Rust":

"Андреас Клинг, основатель проекта Ladybird, поделился своими мыслями о Rust. По мнению Клинга, хотя Rust обладает впечатляющей экосистемой, он менее удобен для разработки долгоживущих программ с большими сложными графами объектов. Кроме того, Клинг охарактеризовал сообщество Rust как токсичное"

Вот, что называется, подпишусь под каждым словом. И про сообщество, и про то, что браузер писать на Rust - гиблое дело, из-за сложности модели данных, и ограничениях, накладываемых на нее системой типов Rust. Проект Servo провалился не просто так. Да, я знаю про пару попыток оживить его (одна из последних - https://wusyong.github.io/posts/verso-0-1/), но, простите, вот когда напишут - тогда и поговорим, ага.

А ребята хороши - https://pypi.org/project/ultralytics-thop/

#rust #meme 🥲

Source

/me

https://t.me/tech_b0lt_Genona/4609

Тут вот коллега очень хорошо, со ссылками, написал про новый мод к doom 2.

В демке меня очень впечатлили воксельные модельки, с одной стороны, полностью сохранили look & feel оригинальных спрайтов, а с другой - очень органично добавили 3D.

А, еще про воксели не могу не поделиться https://www.pouet.net/prod.php?which=4662 https://www.youtube.com/watch?v=_zSjpIyMt0k (олдфаги тут должны смахнуть скупую слезу), эта штука выдавала хороший FPS на 286 процессоре от Intel!

Разработчики этого VPN знают, как должен выглядеть продающий текст.

Доступнее об истории просмотров вам никто не расскажет.

https://www.phoronix.com/news/sched_ext-Ahead-Of-Linux-6.12

Linus жмется, и не пускает #sched_ext в ядро.

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

Ну или, что более вероятно, не хочет оставлять пару заслуженных пенсионеров без гешефта по заносу нужных изменений в переусложненный основной шедулер Linux.

А я-то, было, уже собрал https://github.com/sched-ext/scx, и, потирая ручки, ждал, когда же уже

"The following video is the scx_rustland scheduler which makes most scheduling decisions in userspace Rust code showing better FPS in terraria while kernel is being compiled. This doesn't mean that scx_rustland is a better scheduler but does demonstrate how safe and easy it is to implement a scheduler which is generally usable and can outperform the default scheduler in certain scenarios"

На выходных, от скуки, решил почитать, как это все работает, потому что представления про #ebpf у меня были, в основном, теоретические.

Мама дорогая, сколько они там нахуевертили за 30 лет существования этой технологии, уму непостижимо.

Но, самое главное, они наотрез отказываются пускать через ebpf turing complete код, поэтому, конечно, в текущий момент интересный мне шедулер устроен крайне примитивно - в ядре выполняется только "простой" щедулер, который умеет в round robin внутри каких-то групп процессов, а решения по переносу процессов между группами (довольно медленно!) принимает userspace часть, которая уже и написана на rust (это было про другой шедулер) интересный мне шедулер устроен так - "This BPF backend implements the low level sched-ext functionalities for a user-space counterpart, that implements the actual scheduling policy. The BPF part collects total cputime and weight from the tasks that need to run, then it sends all details to the user-space scheduler that decides the best order of execution of the tasks (based on the collected metrics). The user-space scheduler then returns to the BPF component the list of tasks to be dispatched in the proper order" - не самое рекативное решение.

Понятное дело, что до полноценного сложного шедулера на ebpf пока еще очень далеко.

https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md

Кстати, полезный список ссылок на коммиты, в которых добалялись те или иные фичи #ebpf ядро.

По мне довольно полезно для понимания, когда и зачем срабатывает тот или иной ebpf callback.

Помимо глобального DHT, у человечества есть еще нескольк нерешенных, сложных, проблем.

Одна из них - это консистентная база данных, чуть более сложная, чем K/V (ну, например, чтобы умела хорошо планировать и выполнять cross host запросы), которая хорошо (например, может потреблять значительно разнотипное оборудование в рамках одной инсталляции) скейлится горизонтально, без постоянного облизывания человеком.

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

Помню, как вот эти вот господа https://www.opennet.ru/opennews/art.shtml?num=61730 начинали с помпой, что они ниибацца инженеры из Гугла (или откуда они там были), и сейчас запилят ровно то, что я описал выше.

Во-первых, не получилось, во-вторых, теперь на то, что получилось нельзя даже толком посмотреть.

Очень жаль, начало было интересным.

Доброе утро

Дачный A/B на примере.

На картинке мы видим настоящий "зеленый" A/B +20%, с правой стороны я положил удобрения, на обложке которых было написано, что они "дают насыщенный изумрудный цвет и стимулируют рост", а с левой стороны - не положил.

В удивительное время живем, что написано, то и дают!