Счастье, между прочим, все ближе.

Ну, снова за аниматоров, операторов, актрис, моделей, селебритис.
Моделеров, риггеров, маттепайнтеров, концептеров.
И вот за это вот бессмысленное софтпорно.
Не чокаясь ИИ в городе. Waifudiffusion.

Прогресс просто космический.

Stable Diffusion вырвался на свободу этим летом, а на его базе народ уже творит форменные безобразия.

Да, есть артефакты и любители ловить блох щас будут заглядывать в зубки дареному ИИ. И в глазки.

Но дайте ещё подучиться двухмесячному младенцу. Он покажет зубки.

Меня тут (опять) спрашивают, почему я не люблю проект #GNU. #gold

Расскажу сегодня другую часть этой истории.

Все из-за очень большого разочарования! От любви до ненависти, как известно, не очень далеко.

Я пришел в Linux и в OSS примерно в 2000 году, еще будучи студентом. Знаете, довольно сообразительным, но не очень опытным, знающим. В целом, могу сказать про тогдашнего себя - легко велся на красивые идеи.

Проект GNU, конечно, тогда мне показался чем-то очень волшебным - могучие мейнтейнеры, великий провидец Столлман, Линус, гениальный kernel hacker, вот это вот все.

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

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

Конечно, в какой-то момент случилось отрезвление от всего этого, я понял, что "великие" не пишут код, а занимаются политикой и прочей хуетой, причем в масштабах, невиданных для коммерческих компаний(просто потому, что в компаниях за это дают по рукам, а в OSS они просто "могут").

И что, наоборот, коммерческие компании заинтересованы в том, чтобы было меньше бардака, и что новые xml(тогда еще)-парсеры плодятся в open source, а не в компаниях.

И что если ты придешь в какое-то такое "общее здание", то, за очень небольшим числом исключений, тебя пошлют из-за какой-то ЧСВ-шной херни того или иного мейнтейнера(тут можно вспомнить историю того же gcc и его ast).

В этот момент я понял, что OSS (ну вот даже лично мне) полезен довольно в ограниченном наборе софта*, и что RMS воюет не за что-то общеполезное, а потому что его в детстве обидели, не дав исходники от его любимой lisp машины.

Собственно, GNU я не люблю потому, что они до сих пор вербуют программистов на эту бессмысленную войну, и, тем самым, сегментируют OSS софт на пустом месте.

*: в основном, инфраструктурный софт, протоколы взаимодействия(не только TCP, а еще документооборот, например), и так далее.

https://lkml.org/lkml/2022/9/19/840

Очень controversial переписка между Линусом и фанатами Rust.

Суть довольно простая - товарищи из Rust хотят притащить к себе знание, в каком контексте вызвал аллокатор, чтобы не корячить интерфейс аллокатора заради "странных" хотелок ядра, а Линус совершенно корректно объясняет им, что так делать нельзя:

"And that is FUNDAMENTALLY BROKEN.

If you want to allocate memory, and you don't want to care about what context you are in, or whether you are holding spinlocks etc, then you damn well shouldn't be doing kernel programming. Not in C, and not in Rust"

Потому что пул аллокаций, который можно распределить так, очень мал:

"But it needs to be explicit, because that GFP_ATOMIC pool of allocations really is very limited, and you as the allocator need to make it *explicit* that yeah, now you're not just doing a random allocation, you are doing one of these *special* allocations that will eat into that very limited global pool of allocations."

Я тут испытываю очень противоречивые эмоции.

С одной стороны, ядро сейчас написанно именно так, как рассказывает Линус, и, очевидно, аллокатор надо звать так, как нужно в этом ядре.

С другой - я лично считаю, что ядро надо писать так, чтобы там могло работать 99% любого случайно выбранного кода на соответствующем языке. Вот это вот знание контекста, понимание, что мы сейчас в асинхронном хендлере прерывания - это жесть, надо сделать так, чтобы программисту ядра не нужно было про это думать.

По классике, можно, например, так - https://stackoverflow.com/questions/45095735/top-halves-and-bottom-halves-concept-clarification (попрошу отметить, что в Linux так можно) - в interrupt handler просто сериализуешь данные в область памяти, и кидаешь ее в пул тредов на обработку. Конечно, бывают ситуации, когда надо "ответить" прямо здесь и сейчас, но их можно пересчитать по пальцам одной руки(ладно, я просто больше не вспомнил).

Если посмотреть на какое-нить современное ядро, типа Zircon, то там вообще хрен найдешь это место, которое выполняется асинхронно.

https://www.business-gazeta.ru/article/566137

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

https://discourse.llvm.org/t/clang-16-notice-of-potentially-breaking-changes/65562

llvm начали заранее публиковать о грядущих изменениях, которые что-то ломают.

"The community is trying out a new way to alert interested parties about potentially disruptive changes in pre-release versions of our tools, and this post is the first such attempt at that. We expect to post these announcements to this channel and mark the posts with potentially-breaking so people can more easily be alerted without having to track development progress as closely. We’ve also added a potentially breaking changes section to our release notes to highlight concerns"

"нутром чую, что литра, но доказать не могу"

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

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

Совсем забыл написать про фееричный баг от Intel:

"Ошибка в ядре Linux 5.19.12, потенциально способная повредить экраны на ноутбуках с GPU Intel"

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c

Заслуживает тут внимания, конечно, тот факт, что "уважаемым людям" можно и в минорный релиз насрать закоммитить что-то, сильно сложнее багфикса.

https://www.kommersant.ru/doc/5605730

"Вооруженные силы Украины заявили, что в работе спутниковой сети Starlink наблюдаются перебои, сообщает Financial Times со ссылкой на украинских чиновников. По их словам, проблемы со связью особенно усилились на территориях, которые присоединены к России — в ДНР, ЛНР, а также в Херсонской и Запорожской областях. Основатель SpaceX Илон Маск написал в Twitter, что не может комментировать ситуацию на поле боя"

https://3dnews.ru/1012993/komanda-spacex-starlink-soznalas-chto-otpravila-na-orbitu-30-tisyach-kompyuterov-na-linux

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

Писал, пишу, и буду писать, что security by obscurity, как один из компонентов обеспечения безопасности - хорошо!

А так - пошел на чёрный рынок, купил пару дыр задорого, и вперед.

https://www.ixbt.com/news/2022/10/08/intel-horse-creek-risc-v-intel-4.html

Интересная тема, Intel дает возможность делать чужие процы на своих мощностях, причем, насколько я понял, этот техпроцесс сама Intel еще не использует в своих решениях. Такая отладка "на кошках".

https://www.phoronix.com/news/Zink-Evolve-OpenGL-API

Я уже примерно год рассказываю про то, что #zink + vulkan - это будещее графических API под Linux, но вот тут товарищи заходят даже несколько дальше - пишут, "берите vulkan, zink над ним, и дотачивайте его под свои нужды, как более простое графическое API".

В каком-то смысле это смещает восприятие opengl как "еще один (игровой?) движок поверх vulkan", наравне с тем же unity, unreal, etc.

https://www.phoronix.com/news/Wayland-Protocols-1.27

"The content type hint notification is used for enabling clients to provide hints to the Wayland compositor around the type of visual content provided by the app. In turn the content type hint notifications can be used for the compositor to adapt its behavior. This content-type-v1 protocol was originally written last year and initially supported "content types" are photo, video, or game content. If hinted to be game content, the compositor may optimize for reduced latency, if video it may be optimized for reduced stuttering and better scaling, or photo type for minimal extra processing by the compositor. With this content-type protocol still being in staging, it's possible other content types will still be added but ultimately is left up to the compositor if/what to optimize based upon the various content types"

У нас тут очередной #wayland moment, если вы понимаете, о чем я.

Давайте я быстренько расскажу, какую оптимизационную задачу вынужден решать wayland compositor, как ее решать правильно, и что предлагают эти наглухо упоротые люди.

(это упрощенная схема, как оно устроено "на самом деле" я представляю, но для объяснения сойдет)

Аппаратная начинка вашего монитора и видеокарты должна выдавать какой-то фиксированный RPS. Давайте для простоты вычислений скажем "20 RPS".

То есть, каждые 50ms композитор должен выдавать буфер, откуда аппаратная начинка нарисует нам следующий кадр. Если этот буфер будет меняться в момент отрисовки(например, кто-то продолжит в него писать уже после того, как отдали буфер на отрисовку, или кто-то будет генерить новый буфер быстрее, чем надо), то у нас случится тиринг, BTW.

Как это можно сделать?

(здесь и далее я намеренно не рассказываю, как это все взаимодействует с вводом, потому что это усложнит все в 10 раз)

Самый простой вариант - раз в 50ms делать gather от всех клиентов композитора, блендить их в результирующий буфер, сделать usleep(50 - X), где X - время выполнения gather + blend, и отдать готовый буффер.

С этим решением есть следующая проблема - картинка на мониторе будет отставать от логики приложения на сколько-то времени. Потому что после того, как сделан gather, логика приложения продолжает "тикать".

Это будет ощущаться как постоянный лаг(курсора мышки, нажатия на элементы интерфейса, a/v desync, лаги в играх).

Самый простой способ "пофиксить" это - это сделать usleep() на какую-то константу перед началом всей этой процедуры, так, чтобы и рыбку съесть и окна успели отрисовать себя, но и так, чтобы мы не вывалились за deadline на рисование этого кадра.

(кстати, теперь вы знаете, что делает опция max_render_time в sway, как ее тюнить, и почему она плохо работает)

Одно из правильных решений этой задачи - отдать ее на откуп приложению. Например, делать gather с самого начала кванта в 50ms, и передавать в приложение deadline(скажем, если blend занимает 10ms, то можно передать в качестве deadline now() + 40ms).

Тогда приложение, зная, сколько оно будет рисовать кадр, сможет предпринять нужные действия(например, межкадровую интерполяцию для видеоплеера, или usleep в игре).

Конец рассказа про compositor internals.

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

И, к гадалке не ходи, GNOME media player будет знать, как работает GNOME compositor(какая там логика), и в GNOME shell оно будет работать прилично, и лагать под другими композиторами.

#llvmweekly

У нас сегодня рыбный день новостей про LLVM, потому что там случилось много чего интересного.

https://discourse.llvm.org/t/macro-performance-lexer-and-sourcemanager/65713/2

Например, простыня про скорость clang.

TL;DR:

* clang собирает ядро Linux значимо медленнее, чем gcc. Это, наверное, ожидаемо, потому что clang всегда был больше про С++, а gcc, по историческим причинам, про С.

* clang больше времени проводит в самом себе(парсер, семантика, etc), чем в оптимизаторе, и это, конечно, очень неожиданно.

https://www.phoronix.com/news/LLVM-Clang-15-Benchmarks

А вот бенчмарк кода, собранного clang15 vs clang14.

Примерно 1% в среднем по больнице, что приятно.

Миша с phoronix жалуется, что не как в "старые добрые" времена, когда clang только-только появился, но, блин, отрасль уже "заматерела", все низковисящие фрукты съедены, и никаких прорывов в науке оптимизации не предвидится.

https://reviews.llvm.org/rGd5090cd94a8f

Продолжает приземляться поддержка сборки llvm/clang в один большой бинарник, #busybox-style

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

Ожидаю, что размер пакета с clang упадет в 2 - 3 раза. В перфе роста не ожидаю, потому что 99% времени все равно жрет компиляция, и факт того, что всякие ar/lld/etc будут использовать те же кеши, что и бинарник clang, особой роли играть не будут.

И последняя новость из мира LLVM на сегодня.

https://llvmweekly.org/issue/458

"LLVM’s libc gained implementations of fork, rand, srand, waitpid, wait4, execv, execve, kill, strerror_r, and strsignal functions. e3638e8, 38b6f58, 995105d, 3f96581, 9015810, a9f95b7, 07793f9"

Коллеги прямо очень быстро пишут libc от LLVM.

Я осторожно скажу, что не ожидаю ее готовность к концу 2022, но вот в первой половине 23 надеюсь уже "пощупать" (ЕБЖ, конечно).

Лично для меня это самый ожидаемый проект от экосистемы LLVM(после, собственно, самой llvm/clang/lld), потому что, писал и буду писать, авторы что #glibc, что #musl - негодяи с завышенным ЧСВ, и появление еще одного конкурента на этой делянке - это very appropriate.

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

"Постановление предписывает:

Создание национального репозитория ПО с открытым кодом;
Размещение в репозитории программного обеспечения, созданного, в том числе, за бюджетные средства, для повторного использования в других проектах;
Формирование нормативной базы для публикации ПО с открытым кодом"

Звучит это все интересно, но несколько туманно, не очень понятно, какой софт, в итоге, откроют.

Код госуслуг откроют? Или вот код, который определяет номера оштрофаванных за превышение скорости машин? Или код поиска уклонистов от мобилизации?

UPD: в комментариях предложили назвать это "ГИТЛАГ", звучит хорошо!

https://lwn.net/Articles/910848/

Совершенно прекрасная новость - какой-то патентный тролль собирает патентный пул, чтобы доить пользователей Opus, кодека, специально созданного для того, чтобы быть свободным от разных там патентных претензий.

Насколько я понимаю, кодек - лучший в своем классе, широко ли применяется - не знаю.

https://determinate.systems/posts/qemu-fix
https://www.phoronix.com/news/Linux-6.1-Faster-9P

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

Этот текст - не про то, как "мы все сделали хорошо", а про то, как "все на самом деле плохо".

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

Поэтому и возникают вот такие вот высеры, "как я героически добавил куда-то хештаблицу".

Буде qemu и Linux написаны на нормальных языках, где использование контейнеров не доставляет боль, там или с самого начала была бы хеш-таблица, или чувак, заметивший и пофиксивший это не попал бы к Линусу в блог и на главную страницу phoronix.

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

https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide
https://lwn.net/ml/fedora-devel/CACBV9Zgr_wpM2vkTL=7Mtn+u+8vTHHELfUdnVtavgXhxrwv5dQ@mail.gmail.com/

Федора перестала поддерживать аппаратные кодеки "из коробки".

Я, признаться, не понимаю, зачем эти кодеки вообще нужны, кроме как если вы хотите показывать 4k видео с raspberrypi, но это в любом случае грязное извращение.

Наверное, это имеет смысл во всяких телефонах и планшетах, но не на десктопе.

По мне так все эти аппаратные vdpau/vaapi больше похожи на пузомерку у фанатов Linux - постоянно вижу на всяких форумах срачи про "а у меня не работает va* в firefox/etc", с предложением вправить руки.

Ну и, наверняка же, они дают разный результат у разных вендоров железки, да?

Я собираю #mesa без их поддержки.