commit -m "better"

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, надо поднапрячься!

Я не пользуюсь ИИ, я пользуюсь своей администрацией — Путин Президент также добавил, что мозг человека превосходит ИИ по нейронным связам и имеет низкое энергопотребление, ему не нужна АЭС Поздняков. Подписаться

Вы думали я забыл про #shell? Да, от #shell у меня плавно отпочковался терминал для него #shitty, но #shitty готов, и теперь можно вернуться к родительскому проекту! У проекта теперь новый дом, и новое название - #impulse! https://github.com/impulse-desktop/shell - собственно шелл https://github.com/impulse-desktop/suite - набор пользовательский программ, типа просмотрщика изображений и прочего, все поверх #imgui. Собственно, про просмотрщик изображений далее и пойдет речь. Год назад я бы взял image magick, тем самым, поддержал бы все форматы, и был бы доволен, как слон после трехведерной клизмы. Но: * У IM плохая карма история CVS, а просматривать изображения приходится из совершенно разных источников * #LLM позволяют славно заебаться, на пустом месте Поэтому я сделал #изящно - собрал IM в #WebAssembly, и запускаю декодер изображений в песочнице. В целом, это похоже на то, что делает firefox, со своим https://rlbox.dev/, но, как обычно, есть нюанс - мне удалось собрать такой IM, который не зависит от host системы, ни через emscripten API, ни через #WASI. Ровно одна экспортируемая функция - decode(ptr, len) -> ptr, чистый WebAssembly! AFAIK так еще никто не делал, и это было не супер просто, несмотря на то, что мой #ix умеет в кросс в WebAssembly. Что?! Как?! А вот так! Мне показалось, что этот артефакт может быть полезен широкому кругу людей, особенно тем, кто занимается обработкой изображений в облаках, поэтому я из этого сделал отдельный проект, со своим CI, и со своим релизным циклом - https://github.com/pg83/decode Все просто - качаете оттуда decode.wasm, и встраиваете куда хотите, в любой #wasm runtime, так как, повторю, у артефакта 0 зависимостей от host системы. На КДПВ - #perf конструкции. В целом, замедление небольшое, учитывая bounds check на каждый memory access, не так уж и плохо. Ну и нет нужды в переписывании всего и вся на almost blazingly fast, probably memory safe.

Пока рассказывают про Grok Bot и Muse— в документации уже указано, что: 1) да, будет тир за $500. Пока без информации по лимитам. 2) В НЁМ БУДЕТ УЛЬТРА ФАСТ ДЛЯ АСТРЫ (!), и в будущем для Sol. Поздравляем команду Cerebras, которая смогла развернуть такую огромную и мощную модель у себя. Очень жду. 3) также уже вышел Sol-6.1, цена та же, но кэш дешевле в 2 раза. По метрикам ближе к Astra, не смотрится так позорно, как Sol-6 (неделю назад...). Попробуем.

Красота какая! Оказывается, от AI не только тупеют, но еще и умнеют!

Тут случилась страшная вещь: преподаватели Гарварда оказались хуже, чем натренированный ими же ИИ. Это соревнование завернули в исследование для аж журнала Природа. Почему ИИ победил? Потому что он терпеливый, не устаёт и много чего знает про каждого ученика. Но по большей части — потому что базу ему готовили лучшие из лучших. Короче, суперавторитетный ответ — да, ИИ может обучать студентов лучше, чем преподаватель на удалёнке. Так что теперь следующие, за кем придут технологии — это учителя. Поехали по работе: — Проблема современного образования в том, что лекции (когда преподаватель говорит, а студенты только слушают) дико неэффективные и скучные. — Передовые университеты перешли на активное обучение — когда студенты на занятиях решают задачи в группах и постоянно взаимодействуют с педагогом. Это работает лучше, но у такого подхода есть предел: один преподаватель не может подстроиться под скорость и уровень каждого из 100 студентов в аудитории. — Идеальный вариант — это персональный репетитор для каждого, но это невозможно масштабировать. — С появлением LLM появилась надежда на автоматизацию репетиторства. Нужно было избавиться от галлюцинаций (хотя бы большинства) и угодливости. В 2025 взяли GPT-4 с модификациями: — Надо дробить сложные задачи на мелкие шаги, чтобы не перегружать мозг студента. — ИИ должен поощрять усилия («молодец, ты на верном пути»), чтобы формировать у студента установку на рост, а не страх ошибки. — Чтобы ИИ не врал и не ошибался в физике, ученые заранее жёстко прописали правильные пошаговые решения всех задач. Нейросеть использовала свои языковые навыки только для общения и направления студента. Модель обучения, задачи и т.п. — всё жёсткое как удар серпом по молоту. Для проверки устроили рандомизированное контролируемое испытание на 194 студентах. Учили гидродинамику. — На старте средний балл был 2,75 из 5. — После профессора-человека — стал 3,5 из 5. — После ИИ-репетитора — 4,5 из 5. Разница статзначимая. — Живое занятие в классе длилось 60 минут. А вот медианное время работы с ИИ — 49 минут. Те студенты, которые жаловались, что живые лекции для них «слишком быстрые», сидели с ИИ дольше обычного, спокойно разбираясь в материале. А те, кому на лекциях скучно и медленно, пролетели материал с ИИ гораздо быстрее. — Уроки с ИИ показались студентам более увлекательными (4,1 балла против 3,6 за живой класс) и мотивирующими (3,4 против 3,1). — 83% студентов заявили, что объяснения искусственного интеллекта были такими же или даже лучше, чем у живых преподавателей Гарварда. Ограничения работы: — Опять выборка только из студентов ) — Задачи были на изучение, а не на синтез знаний — следующий тест нужен на, например, инженерное конструирование, а не теорию. — ИИ сработал так хорошо потому, что учёные потратили кучу времени на написание идеальных инструкций и дали ему очень хорошо подготовленный курс. Без преподавателей это работать не будет. Они всё ещё нужны, но теперь лучшие из лучших могут масштабировать свою работу и уволить 90% остальных. — Учёба с ботом — одиночный процесс, выпала часть командности. Тук-тук, преподаватели! Вы следующие. -- Вступайте в ряды Фурье! | Самые умные посты Если бы мне платили каждый раз 5 рублей, когда я проваливаю экзамен по математике, у меня уже было бы уже 97 рублей!

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6868618 https://t.me/crimsondigest/2135 Несколько человек мне кинули ссылку. Мол, школота тупеет от AI. 1) Не тупеет, а хуже сдает экзамены, придуманные в до-AI эру 2) https://sk.ru/news/nasha-matematika-byla-absolyutno-chempionskoy/ - Пару лет назад я встретил его в Независимом университете и спросил: «Николай Николаевич, как народ»? Он говорит: «Ой, ой, ой, ой!.. Ну деградация полнейшая, конечно, деградация!.. Но решают лучше!..» - это было сказано не про AI, а про засилие гаджетов Коллеги, 500 лет назад люди были тупее, чем сейчас, если у них не было понятия про матанализ и теорию вероятностей, или не были? А 5000 лет назад, когда не умели делить столбиком, были тупее, или нет? Вопрос риторический. Отсутствие тех или иных конкретных знаний != отупению, люди как умели составлять сложные логические конструкции, так и продолжают уметь, и неважно, как это конкретно устроено сейчас. Люди начнут тупеть, когда исчезнет конкуренция, а не от появления нового инструмента. Поэтому бояться стоит появления базового дохода, например, а не AI.