https://www.phoronix.com/review/ubuntu-o3-experiment/5 #O3

Как ни странно, хороший perf test от Миши с похороникса.

Почему?

Потому что показывает ровно то, что и должен показать - что Ubuntu, собранная с -O2, работает с той же скоростью, что и Ubuntu, собранная с -O3.

Понятное дело, что коллега, как обычно, пытается развести чепуху на постном масле о 5 страницах, но среднее геометрическое на последней странице как бы говорит нам, что нет никакой разницы.

- Тут ещё одна проблема. У вас формат данных описан в 3 местах, и везде по-разному. Нам по какому из описаний пакет разбирать?
- О, сразу ощущается недостаток инженерного опыта. Незамутнённый оптимизм: вера в то, что если в документации написано в 3 местах по-разному - то в одном из них почему-то непременно правильно.

Небольшое дополнение к этому тексту. #wayland

Оказывается, Simon Ser писал wlroots не по доброте душевной, а за деньги, и теперь собирается "приглушить" свой вклад, потому что больше не работает на проклятого SJW #ddv:

"even Simon Ser recently said he'll have to tone down his contributions due to the termination of his contract with SourceHut - I wish you all the best wherever you end up, Simon"

Такими темпами wlroots превратится в очередной мертвый стандарт от freedesktop, и туда ему и дорога:

"Further reasons could include slow development pace - new wayland features that require changes in wlroots tend to take ages to get merged into wlroots, like for example tearing, where a basically ready MR took 9 months to merge because of 100 "style nits" and 2 actually important remarks, or explicit sync still not being a thing, despite KDE and Gnome having implementations already"

#rant #cosmic

Сподобился собрать https://lapce.dev/, просто чтобы позырить на GUI в Rust.

Вот, оно падает, с очень похожей диагностикой на cosmic-term, не совсем в том же месте, но по коду где-то рядом, не может найти шрифт:

https://gist.github.com/pg83/298157ce4f9296a690723c0eab41aa9e

Удобство использования сторонних библиотек - это хорошо, но зачем же вот эту вот сырую гадость, которая еще не вышла из беты, тащить в проект?

Только чтобы не зависеть от C/C++ кода для рендеринга шрифтов? Или они там красивее?

Чтение кода ни к чему интересному не привело, скажем спасибо очень продуманной лучшими экспертами-языковедами системе обработки ошибок, когда у тебя программа падает в произвольном unwrap(), без вообще никакого стека из того места, где реально случилась ошибка.

Не согласны - ну, вот, по ссылке https://github.com/pop-os/cosmic-text/blob/main/src/shape.rs#L251 крейт и строчка кода, расскажите, как оттуда получить норм ошибку.

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

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

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.