commit -m "better"

В процессе работы над #impulse мне понадобился рендер svg. Как для самого #shell, так и для условного просмотра изображений. Изначально я взял #lunasvg, но мне стало интересно, че там и как сейчас на этом рынке. Сравнил самые известные standalone рендеры svg: #lunasvg #svgren #resvg librsvg ThorVG #inkscape Skia И SOTA рендеры - chromium, firefox. TL;DR - chromium и firefox совпадают на 95%, а resvg совпадает с каждым из них на 90%, и, тем самым, resvg - самый лучший standalone svg рендер. Все остальные далеко позади, не дотягивают и до 70% совпадений с SOTA. Но проблема resvg в том, что он написан на rust, а rust в мире LLM больше не нужен - https://t.me/itpgchannel/4486 Поэтому я взял, и запустил простенький #autoresearch цикл: * 7500 svg из тестов resvg, chromium, skia, firefox, и еще откуда-то * 10000 svg с просторов интернетов (все это оптимизировано по покрытию фич, которые требуются от рендера) * 17500 прикопанных png "как svg выше рендерит chromium" * простая метрика по разнице того, как это рендерим мы (начиная с белого холста), и SOTA решения https://github.com/impulse-desktop/svg Думаю, через несколько часов тут будет лежать очень качественный svg рендерер, который я уже потом доведу по #perf до SOTA решений.

500 больших проектов в #trustme, с прогоном тестов, каждая следующая пачка все проще и проще. И это с учетом того, что я теперь +100 новых проектов тащу для +1 версии самого компилятора, вот прямо сейчас бездушная машина тащит +100 проектов для rust 1.93 (начинал с 1.90), а это уже как минимум компиляция всего libstd!

https://www.opennet.ru/opennews/art.shtml?num=66425#12 TL;DR - flathub дал заднюю со своей политикой про AI. И очень жаль, его подход мне совсем не близок, и было бы неплохо, если бы он тихо помер!

Рунет: чем централизованнее, тем уязвимее. Удар по дата‑центру Яндекса побудил многих «околовоенных» экспертов высказаться на темы, близкие к кибербезу. Давайте мы, как профильный канал, тоже прокомментируем эту тему. Все мы помним, что Рунет у нас уже много лет суверенен, независим и достаточно централизован. Он буквально завязан на несколько ключевых провайдеров и их дата‑центры. Проект централизации первично децентрализованной технологии «Интернет» выполнялся по различным причинам — их мы обсуждать в этом посте не будем. Но фактически успех этого проекта привёл к тому, что буквально на около десятка дата‑центров в европейской части России завязано функционирование примерно всего Рунета. Поэтому, господа военные эксперты: может, суммарно дата‑центров у нас и сотни по всей стране, может, и очень крупных много. Но вывести из строя нужно гораздо меньше, и они вовсе не на Камчатке. Их нужно питать, обслуживать, обеспечивать логистикой. Они все в полётной доступности средств поражения по вполне прагматичным причинам. Могут ли облачные провайдеры быстренько «переехать» в безопасные дружественные страны? Конечно, нет. 152‑ФЗ («О персональных данных») жёстко ограничивает в этом, а 187‑ФЗ (регулирующий безопасность критической информационной инфраструктуры) вводит прямо запрет на зарубежные облака и SaaS‑сервисы. Централизация тут однозначно стреляет нам в ногу: в плане физического поражения инфраструктуры мы стали уязвимее.

https://github.com/pg83/decode/releases/tag/5 - а теперь еще и детектор mimetype, из libmagic, которая часть file! #impulse

Ровно по такой же схеме, понадобился memory safe PDF render, для #impulse, а на JS у меня аллергия, потому никаких pdf.js. https://github.com/pg83/decode/releases/tag/4 Вот, теперь тут живет не только Image Magick, но еще и PDFium от гугла, собранный в #WebAssembly, а еще, для полноты картины, djvulibre. Если вы занимаетесь обработкой pdf в облаках - то вам это, несомненно, очень надо!

OpenAI just dropped 700 preprints of mathematical proofs and counterexamples Article, Comments

Внезапно ускорил #perf еще на 7%, довольно простой идеей - программа, которая масштабирует изображение, может быть разделена на 2 части - ту, что обрабатывает тайлы по краям, и ту, что обрабатывает центральные тайлы. Первая программа должна содержать в глубине цикла проверки на выход за границы текстуры, ну или можно сделать 8 разных таких программ, но они тогда будут зависеть от ширины и высоты текстуры, и от ее положения на общей канве, а во второй программе такие проверки можно убрать! Проблема в том, что программ стало очень много, и их перестроение стало заметно при ресайзе окна плеера, по причинам что я выше написал. Решил и эту проблему, весьма #изящно - программы компиляются и оптимизируются в отдельном тредпуле, а пока они не готовы, используется тот самый generic шейдер, про который я писал в https://t.me/itpgchannel/4499 Получилось прямо очень хорошо, реактивно!

https://www.opennet.ru/opennews/art.shtml?num=66406 Ветка Mold 3.0 примечательна переписыванием кодовой базы с C++ (C++20) на язык Rust. Mold 3.0 может использоваться в качестве прозрачной замены Mold 2.42.1, последнего выпуска на языке C++, и поддерживает все ранее доступные опции и целевые архитектуры. Переход на Rust позволил обезопасить проект от потенциальных проблем при обработке повреждённых объектных файлов - в ситуациях, когда версия на С++ аварийно завершалась из-за обращения к областям памяти за пределами буфера, вариант на Rust останавливает работу на этапе проверки границ. Производительность реализации на Rust находится на одном уровне с версией на C++. Ну все, пизда проекту.

https://ayles.github.io/doom-in-kernel/ Коллеги (на этот раз действительно коллеги!) подогнали прекрасное - Doom, на #eBPF, в ядре Linux. "Прекрасное" потому что идет наперекор тому, как пытается работать eBPF. eBPF, для каждой загружаемой программы, пытается доказать, что программа не зависнет, и что программа не ездит по памяти. Второе, допустим, просто, поколения программистов вычистили исходники Doom так, что игра работает и без проездов. Первое - сложно, и чуваки поступили, на мой вкус, весьма #изящно! Они запилили свой компилятор поверх LLVM. Он режет обычный C-код на "регионы" - куски без сложных циклов и вызовов. Регион обрывается на каждом вызове функции, возврате, неудобном обратном ребре цикла или yield. В конце он сохраняет state в память, и возвращает номер следующего региона. Регионы гоняет маленький диспетчер из трёх вложенных ограниченных циклов: 32x2048x64, около 4*10^6 регионов за один вызов. Если бюджет кончился, программа возвращает "не доделано" с номером продолжения, и userspace вызывает её снова. Ну а верификатор доказывает завершение не DOOM, а очередного региона и диспетчера. И он может это сделать, потому что видит набор кусков, каждый из которых заканчивается обычным return, плюс цикл с константной границей. Прыжков "регион 18 -> регион 42" в графе управления нет: это число, записанное в память. Рекурсия, глубокие вызовы и длинные циклы существуют только во время исполнения, как последовательность этих чисел. Я бы тут поинтересовался у коллег, почему того же самого нельзя было добиться source трансформацией кода, превратив его в async код через с++ корутины, трансформация ровно та же самая получается - куча блоков с return, и цикл dispatch над ними сверху, но сути это не меняет.

За прошедшие сутки все стало еще намного круче! Изначально та моя схема страдала довольно посредственным качеством, потому что мне нужно было одновременно скомпозировать виджеты imgui, которые рассчитаны на блендинг в sRGB, с результатом от моего крутейшего скейлера, и за один проход, без нескольких дополнительных тяжеловесных текстур, это было возможным сделать только в том же sRGB. А сам скейлер был билинейным, и блендинг всего этого в sRGB давал так себе результат. Я проитерировал несколько дизайнов, и сейчас рендер моего video player устроен так: 1) отказался от фрагментных шейдеров, теперь сырой тайловый compute, это уровнем еще пониже, чем обычный vulkan. 2) каждая сцена делится на тайлы 8x8 и 24x24, адаптивно, в зависимости от контента тайла. Для каждого тайла мы получаем все текстуры с их передаточной фуункцией, и геометрию imgui, которые лежат на этом тайле. 3) если тайл покрыт только виджетами imgui, выбирается один compute простой compute, который рендерит геометрию сразу в целевой формат поверхности. Если тайл покрыт только видео, то используется передаточная функция текстуры (тот самый мой IR, про который я рассказывал в прошлый раз), которая тоже сразу рендерит в целевой формат. Если есть и геометрия, и другие текстуры, то включается самый тяжелый шейдер, который все в памяти тайла (без промежуточных текстур) приводит все в линейное пространство, блендит, и переводит все это в целевой формат поверхности. Это тяжелое ядро, в нем больше всего вычислений на один пиксель, и его в реальной жизни почти никогда не бывает (это условное osd menu от imgui поверх видео) Как сделать эффективнее, я, наверное, и не знаю, машина говорит что это SOTA подход для 2D рендера. Все это позволило разумно поддержать hdr, сделать качественный lanczos фильтр масштабирования в линейном свете, "как в libplacebo" (а это современный SOTA для качественного масштабирования), на моем стенде с перцептивными метриками качества SSIMULACRA2. И я все еще быстрее SOTA libplacebo, примерно раза в 2, зависит от входных форматов и алгоритмов масштабирования, при том же уровне качества! Все потому (ну кроме моего оптимизатора IR ядра под задачу), что, так как libplacebo не "владеет" всем pipeline, им приходится лишний раз материализовать промежуточные буфера в линейном свете, а это еще и по памяти весьма дорого!

Госучреждения Нидерландов и Франции внедряют решения на базе NixOS https://www.opennet.ru/opennews/art.shtml?num=66367

В разработку проекта вовлечены три государственные IT-компании - DICTU, SSC-ICT и DUO-ICT. Первый стабильный релиз DAWO ожидается в следующем году. В настоящее время в пилотном внедрении платформы участвуют четыре муниципалитета. Наработки опубликованы на государственной платформе совместной разработки, созданной на базе Forgejo, и зеркалируется в Codeberg. Платформу DAWO образуют несколько компонентов: - Операционная система DAWO-NixOS на базе NixOS (отдельно предусмотрен резервный вариант на Fedora Kinoite). - Облачная инфраструктура DAWO-Cloud. - Инструменты для организации совместной работы MijnBureau на базе Nextcloud, Collabora, Element и OpenProject. - Система идентификации и управления доступом DAWO-IAM. - Инструменты централизованного развёртывания и управления рабочими станциями DAWO-Sextant. Для управления мобильными устройствами планируют использовать Fleet. - Мобильная платформа DAWO-Mobile, в качестве основы для которой рассматриваются /e/OS, GrapheneOS и CalyxOS. - AI-ассистент DAWO-AI. Дистрибутив NixOS выбран в качестве основного для рабочих станций из-за декларативной модели конфигурации, поддержки воспроизводимых сборок, возможности работы на устаревших системах, наличия средств для аудита и отката изменений, а также развития сообществом без влияния отдельных корпораций. На выбор NixOS также повлияло то, что курирующая проект NixOS некоммерческая организация зарегистрирована в Нидерландах, а авторы пакетного менеджера Nix и первого варианта дистрибутива имеют голландские корни. В качестве претендентов рассматривались openSUSE и Fedora, но были отклонены из-за влияния на их разработку отдельных компаний. Похожая инициатива по созданию решения для госорганов на базе NixOS параллельно запущена во Франции. Проект развивает Межминистерское управление по цифровым делам (DINUM) для обеспечения цифрового суверенитета и независимости от иностранного ПО. Для системных администраторов разработан защищённый вариант дистрибутива - Securix, а для обычных пользователей предлагается использовать шаблон Bureautix, который различные ведомства могут адаптировать под свои нужды.

Репы https://code.overheid.nl/MinBZK/DAWO-NixOS https://github.com/cloud-gouv/securix

https://www.opennet.ru/opennews/art.shtml?num=66392 "Компания System76 внесла в правила приёма pull-запросов для среды рабочего стола COSMIC и в соглашение об участии в разработке дистрибутива Linux-дистрибутива Pop!_OS требования, запрещающие передачу в изменениях или сообщениях о проблемах содержимого, сгенерированного с использованием AI-инструментов. Запрет касается кода, комментариев и текстовых описаний. Вначале в правилах было упомянуто о допустимости использования AI для проведения исследований, тестирования и других похожих задач, но затем это примечание было удалено" Еще один OSS поект решил самоубиться на рвном месте, ну и ладно.

Че-то очень странное, openbsd отказались принять порт с uutils в дерево. То есть не то чтобы как замену своим утилитам, а как просто пакет со сборочными файлами.

OpenBSD Developers Reject Uutils Coreutils Article, Comments

История одной #perf оптимизации Для #impulse мне нужен видеоплеер, с gui на #imgui. Нужен и нужен, с #LLM это очень просто, он случился у веня за 1 вечер, мне нравится. Но вот в его рамках случилась одна интересная #perf задачка - fused scale + color conversion. Задача довольно простая - на выход из декодера у тебя есть текстура в цветовом формате A и разрешением XxY, ее надо отмасштабировать в разрешение X2xY2, одновременно поменяв цветовое пространство, чаще всего в RGBA, или линейное. В ffmpeg есть софтверный скейлер, он хорошо оптимизирован на CPU, но на 4к довольно таких неплохо заметен в профиле. Challenge accepted! Далее прямо по стадиям, как я это оптимизировал. 1) Ffmpeg отдает дескриптор формата, его можно загрузить в shader, как константные данные, и тупо написать код, который проинтерпретирует этот формат, для всех пикселей поверхности. Это ОЧЕНЬ неэффективно делать на CPU, но на GPU это дало хорошее ускорение, и на самом деле, тут уже можно было бы остановиться. Но тогда я был бы не я! 2) Cпросил клоду "вот тут у нас куча мертвых ветвей в шейдере, которые гейтуются внешними константами, которые мы ему передаем как параметры". Машина мне сказала, чтобы я не ссал, и что оптимизатор драйвера выкинет эти ветви сам. "Ага", сказал я, и посадил клоду пилить стенд - взять 50 самых частых комбинаций типов поверхностей, которые надо туда-сюда преобразовывать, написать руками 50 шейдеров, и оптимизировать их, один за одним, каждый раз проверяя, что наш generic шейдер выдает тот же самые результат, что и оптимизированный, и что он совпадает с результатом swscaler от ffmpeg. Результат - generic шейдер в 3 - 4 раза медленнее оптимального. 3) Посмотрели с клодой на данные, поняли, что шейдер можно представить как формат входа X передаточкая функция (12 штук примерно) x выход. Всего 2000 разных шейдеров, каждый вхож/выход/передаточная запрограммированы руками. Сделали из шейдера jinja шаблон, кодогенератор встроили в сборку, 2000 шейдеров строятся несколько секунд. Результат - ну примерно x2 от руками оптимизированных, то есть, еще в два раза хуже. 4) Подумали, посмотрели на разницу между кодогенерацией и ручным кодом, поняли, что некоторые константные знания - "фактоиды" (как вот вход - выход - передаточная выше) позволяют значительно все ускорить, но тогда декартово произведение всех возможных вариантов становится настолько огромным, что предкомпиляция не выглядит работающим решением. В итоге переписали шейдер на кастомном DSL, сразу в виде IR на Python. Вернее, генератор IR шейдера в зависимости от всех возможных известных нам фактоидов, плюс несколько пассов оптимизации IR поверх. Встроили в тот же кодоген, уже без текста и jinja шаблонов, результат - ровно x1, сгенеренные шейдеры не хуже, чем написанные руками. 5) Можно было бы остановиться, но лучшее - враг хорошего! И я сказал клоде, что раз уж теперь у нас есть IR, который мы сами и оптимизируем, то зачем нам материализация в виде текста? А если так, то переноси IR прямо в с++ код, шейдер поверх этого IR в C++ код, и генери spir v на ходу, по запросу, без предварительной кодогенерации. Машина сидит, пыхтит, работает, красота. UPD: вести с полей: "Все факты, включая размеры и шаги то, что даст рантайм на этапе 2: 0.924. В последней строке yuv444p и yuyv обгоняют ручные на 10%", так что мы еще и обогнали сами себя же! Думаю, наш fused scale + color conversion - самый быстрый на рынке!

Кстати, opus 5.5 теперь моя рабочая лошадка, заменил sol 5.6. Подписка на codex кажется все менее привлекательной - самая сильная модель там хуже fable, средняя (sol 6.1) - хуже opus 5.5, и лимиты эти пидарасы срезали в 2 раза. Товарищи из openai, надо поднапрячься!