Смешных движущихся картинок в ленту!

https://drewdevault.com/2022/06/23/Copilot-GPL-washing.html

https://twitter.com/ReinH/status/1539626662274269185

#copilot #strong_ai

"Machine learning is essentially a glorified pattern recognition and reproduction engine, and does not represent a genuine generalization of the learning process. It is perhaps capable of a limited amount of originality, but is also capable of degrading to the simple case of copy and paste."

Что я тут могу добавить?

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

* Ну, что думает MS про обучение на github, всем понятно. А вот тонкий момент - а что, если обучить copilot на утекших исходниках Windows NT, или закрытых драйверах Nvidia, а потом он начнет делать интересные подсказки для авторов Nouveau и ReactOS? Это вот как будет классифицироваться? Насколько я понимаю, сейчас для кожаного мешка из соответствующих проектов читать такое - зашквар, потом код нельзя писать.

* КМК, Дрю ДеВолт таки пиарит на этом свой хостинг source hut, хотя явно заявляет, что не делает этого.

———
https://news.ycombinator.com/item?id=31846593

Пишут, что Я выложил большую модельку.

Ничего про модельку не знаю.

Обсуждение на HN классное - и про Путина, и про Ирак с Ираном, все, как положено.

600 комментариев - IMHO, довольно дофига.

Пеняют, что не нужно называть OSS проект "cocaine".

Меня попросили, чтобы я делил свои заметки на части, а не вываливал дневной блок одной порцией.

Я уже так пробовал, мне не понравилось почему-то.

Попробую еще раз, потом устрою опрос, как лучше.

#copilot #ddv

https://lwn.net/Articles/898772/#Comments

В продолжение вчерашней темы, обсуждение статьи ДеВолта на lwn.net - https://lwn.net/Articles/898772/#Comments

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

TL;DR - derivative work довольно странное понятие, и оно не может определяться лицензией per se, а пределяется законом. То есть, я не могу в лицензии написать, что вот текст после обработки copilot - это derivative work, с соответствующими ограничениями.

Про хрупкость OSS систем сборок.

Есть такой проект, x265. У него вышла новая версия, я ее обновил, но, почему-то, с новой версией перестал собираться ffmepg, с сообщением от configure, что, мол, x265 не установлен в системе.

configure так посчитал, пому что x265 не установил в доступное место x265.pc, скрипт для pkg-config - основной способ резолвинга зависимостей.

Пристальное разглядывание сборки x265 показало, что установка этого файла зависит от флажка X265_LATEST_TAG - https://bitbucket.org/multicoreware/x265_git/src/9b59d45549f460e41a852cfd276f9b89eed2112a/source/CMakeLists.txt#lines-743

А флажок выставляется только если в системе есть бинарник git, хотя он может и не использоваться для поиска версии в репозитории, если в корне нет папки .git.

Вот так - нет git, нет и x265.pc, и пакета как бы и нету в системе.

Я пока добавил git в зависимости, но так-то у меня для подобных извращуг есть и фейковый git, просто пока не успел его проверить. https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/x265/ix.sh#L22

Мораль? Сборка OSS проектов - это говно и палки, а, иногда, и палок не завезли.

https://roman.pt/posts/dont-let-dicts-spoil-your-code/
https://lobste.rs/s/gzemqn/don_t_let_dicts_spoil_your_code

Тут вот коллега убеждает всех, что не надо использовать словари в питоне для взаимодействия разныхслоев в коде. Пишет, что надо все преобразовывать в классы, и как можно раньше переводить ваши данные из json-like словарей в эти иерархии.

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

Сначала я несколько переформулирую задачу, надеюсь, что без https://en.wikipedia.org/wiki/Straw_man

Учем, что в Python (очень упрощенно, но достаточно для моих нужд)

a.b := a.__dict__['b']

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

Плюсы этого подхода понятны - иногда(pun intended) не нужно менять внутреннее представление при изменении формата данных и протоколов.

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

Минусов же - вагон и маленькая тележка:

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

* Люди, на самом деле, плохо предсказывают будущее, и не везти вам будет сильно чаще, чем хотелось бы.

* В случае использования сырых данных абстракции не текут, а в случае вот такого промежуточного представления, у вас на схеме уже 2 места, где они могут начать протекать. Ну, типа, одного из ваших сотрудников все это заебет, и он положит в полюшко датакласса какую-то аццкую смесь из словарей с внешними данными, и промежуточного представления, а вам потом это рефакторить.

* Performance. На этом не останавливаюсь, и так все понятно. Тут мне могут возразить про туплы и датаклассы - на разборе много потеряете.

* Достаточно subtle вещь, но IMHO важная. В Python dict везде, вы можете очень прозрачно манипулировать этими словарями как объектами, так и как kwargs, и часто это очень удобно. С классами как?

**a.__dict__['b']

? Ну такое.

* На каждое сочетание частей исходных данных классов не наберешься. Я к тому, что разных вариантов нетипизированных словарей у вас может быть очень много(в том числе, data driven), и вам совсем не захочется их все как-то именовать.

* #protaskivanie

Я свои словари разбираю только, если мне нужна полиморфная иерархия классов. И то, я постараюсь словари в поля классов не разбирать, а положить одним словарем все.

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

(Если подумать, то у меня в коде на Python сильно больше словарей и функций, чем классов с методами)

Ну и такое, философское, замечание - вот так вот отказываться от словарей в Python, это как в Lisp от списков.

2 новости, одним блоком, потому что, они, по сути, про одно и то же.

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

Люди запускают ядро Linux в виртуалке во FreeBSD, чтобы использовать драйвер для сетевой карты. Звучит всрато? По мне так огонь - это еще один подход к снаряду "драйвера в userspace".

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

"Применение асинхронной буферизированной записи на базе io_uring до 80 раз снизило задержки в XFS"

Как по мне, обе этих новости про то, что монолитные OS уже отжили свое, потому что современные технологии и практики программирования приводят к тому, что не нужно делать context switch на каждый чих, и выселение сервисов OS в user space не бьет больно по throughput и latency.

Уже писал, и еще раз напишу, что будущее осестроения - это ядра, которые будут заниматься установкой соединений между сервисами, и поддержкой вот таких вот uring между сервисами в user space.

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

Уязвимость в минорной версии openssl. Я подчеркну "в минорной", потому что хочу рассказать про следующий забавный факт.

Примерно в 20 - 30% случаев за каждым релизом какого-то OSS софта, через день-два следует следующий релиз с исправлениями багов.

Тут можно понимающе усмехнуться, и сказать "ну, на то и минорные релизы, чтобы фиксить проблемы мажорных".

Но, дело в том, что это нифига не так - фиксы следуют один за одним именно в минорных релизах. За последнюю неделю:

neovim 0.7.[1, 2]
popt 1.[17, 18, 19?(непонятно, был он, или нет)]
libidn 1.[40, 41]
телега 4.0.[1, 2]
+ топикстартер.

И это только то, что я вспомнил из головы.

К чему это я все?

Не работает этот ваш #semver, хреначат баги в прод без тестов почем зря.

Хочется уже какое-то правило "обновляться на новый код минимум через 2 дня после релиза, если не было следующего". К сожалению, с существующими инструментами это не очень удобно, придется где-то хранить свой state.

https://tass.ru/ekonomika/15055267 #wot

Развитие событий по делу читов для World Of Tanks.

Что я могу сказать? Я не эксперт в юридических словах, но считал, и продолжаю считать, что тут нет "состава преступления".

Есть "unfair" эксплуатация дыр, это когда ты крадешь номер кредитки в чате игры, и есть "fair":

* автоматизация фарминга

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

* AI для прицеливания(не могу найти ссылку на девайс, который прямо в hdmi потоке рисует рамочки для прицеливания в наборе игр)

Чем отличается официальный донат в играх от вот этого? Только тем, кому идут деньги. И в том, и в том случае игрок получает преимущество в игре за деньги.

Турниры? Ну come on, это мелкая и решаемая проблема, начиная от очных турниров, до полной записи на камеру действий игрока, монитора, и так далее.

UPD: в комментах мне пишут, что это нарушение ToS. Это классическая дилемма - отвечает ли производитель ножей за противоправное их применение. Я считаю, что не отвечает.

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

Вот так, анализируя кольцевые зависимости freetype + harfbuzz + cairo + pango, я начал понимать, что мои представления о рендеринге шрифтов в Linux очень далеки от реальности.

#freetype #harfbuzz #fontconfig

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

Потом в эту модель добавился harfbuzz, как загрузчик opentype шрифтов. Модель изменилась так - или freetype, или harfbuzz рендерят в буффер глифы, дальше приложение битблитает их на канву.

(битблитать недостаточно, https://github.com/revery-ui/revery/issues/108)

Эта стройная модель разбивается о:

* Настройки антиалиасинга живут во freetype. Всем известны infinality freetype, и патченый freetype в arch. Как это все соединяетсяс предыдущей моделью? Как антиалиасятся глифы от harfbuzz?

* subpixel rendering в freetype/harfbuzz? Один и тот же код, или разный, с разными настройками?

* Как мы рендерим цветные шрифты и шрифты под углом? Вряд ли мы поворачиваем глифы, кажется гораздо более естественным поворачивать outlines. Тогда пайплайн такой - freetype/harfbuzz готовят outlines, кто-то отдельный их рендерит. Но, если так, то конечным рендерингом должна заниматься какая-то отдельно стоящая векторная библиотека, типа cairo? А откуда она берет настройки антиалиасинга из freetype, и по каким алгоритмам вообще их имплементирует? А как мы рендерим/поворачиваем subhinted glyphs?

А как в обе этих модели вписываются хинты для взаиморасположения символов? В модель с outlines довольно понятно, а вот в bitmap модель не очень.

Причем, достаточно понятно, что есть приложения, которые берут готовые глифы от freetype, и есть те, которые используют outlines.

А если cairo для рисования outlines, то что в QT?

(Я попрошу заметить, что я еще даже не начал писать про подобные неоднозначности в text shape/layout, которыми занимаются harfbuzz и pango, и невесть кто еще)

Да, да, все это я начал понимать, раскапывая списки зависимостей разных там библиотек :) До этого мне правильные вопросы не приходили в голову.

Коллеги, помогите девочке Даше не сойти с ума, и скажите, как оно все на самом деле.

Ну и главный вопрос - чо круче-то, open type или true type шрифты? Как убедиться, что используется ot вариант, и что рендеринг идет правильным путем?

Как вы уже поняли, я умею себе находить друзей в интернете. #vkquake

Вот, только что, видимо, закрыл себе все дороги в Tesla, повздорил с автором vkQuake - https://github.com/Novum/vkQuake/issues/500 https://www.mobygames.com/developer/sheet/view/developerId,567237/

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

Один из коммитеров(не оунер проекта) подсказали мне, что дело может быть в размере стека.

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

Я посоветовал ему, "как perf инженер perf инженеру", чтобы он выделил пертредный буфер нужного размера, и использовал его вместо стека.

Автор кода:

* сообщил мне, что я stupid fool(потерто)

* что он 7 лет оттрубил в id Software, и что он-то уж точно знает, как надо. Я, конечно, сообщил ему в ответ, что 20 лет занимаюсь перфом сложного многопоточного софта, что разозлило его еще больше.

* Параллельно он попытался втюхать мне, что выделение в куче time unbounded, а на стеке - нет. Я, конечно, не преминул рассказать ему про то, что стек выделен в virtual memory, и page fault в нем так же time unbounded. И что предложенный memory pool так же решает эту проблему.

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

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

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

Очень мило, у меня появился персональный фанклуб(кстати, далеко не первый, но про остальные как-нить в другой раз), пока там 1 какой-то странный чувак, который хочет предать меня публичному позору:

Это ещё одно, что я хочу показать. 
Как ты поплывёшь и пойдёшь меня 
тереть после своего позора

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

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

Модерировать я ничего не собираюсь, разве что, конкретную уголовщину, чувака забанил на сутки(уже вернул).

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

У меня случилось продолжение историй про #googlesource и про #gitlab

Напомню, что речь идет про 2 следующих факта:

* системы контроля версий отдают нестабильные tgz с кодом, если речь идет про снепшот, который готовит сама система контроля версий, а не про файл, который зааплоадил, в виде релиза, мейнтейнер проекта.

* freedesktop пролюбили свою инсталляцию gitlab, и поднимали ее из праха.

Короче, я вчера сделал ix gc - это команда удалила все ненужное из системы, в том числе, все скачанные исходники.

И тут началось.

* из-за того, что freedesktop пролюбили кеш артефактов, и из-за проблемы нестабильности генерации tgz, у меня поехали хеши исходников, указанные в сборочных файлах

* пока я прописывал новые хеши, gitlab снова сломался, и начала вместо исходников присылать html с 502, который и закешировался вместо исходников. К такому меня не готовили, и я снова сделал ix gc

* После этого я нашел зеркала нужных мне исходников на github, и прописал их.

Лично меня бесят эти красноглазые пенсионеры, которые, в своей ненависти к MS(а как еще объяснить желание своей инфры в этом месте?) делают больно дистростроителям на пустом месте.

Не надо, не надо, не надо держать свою инфраструктуру там, где это возможно. Особенно если у вас один админ на 10 минут в неделю на этот проект.

github собаку съел на хранении исходников, у него девяток больше, чем букв в слове freedesktop.

#gstreamer #plugins #gold

OSS, построенный на консалтинге - зло, так же как и OSS, основанный на продаже вендорам закрытых версий своего же OSS кода.

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

Вот, например, авторы gstreamer последние 15 лет всем рассказывают, как же динамически загружаемые плагины - это круто.

Но стоило появиться Хуавею, который покрутил пальцем у виска, сказал, что хочет все, как у белых людей, и дал денег, так gstreamer сразу переехал в монорепу, и запилил "почти" статическую сборку.

https://www.collabora.com/news-and-blog/news-and-events/generate-mininal-gstreamer-build-tailored-to-your-needs.html

Конечно, все это сделано максимально говенным способом, накрутили каких-то скриптов поверх meson https://github.com/GStreamer/gst-build/blob/master/scripts/generate_init_static_plugins.py, накостылили прокидывание настроек из основного meson файла в вспомогательные, и, самая мякотка - сказали, "а мы будем собирать все, что найдем, как обычно, а вы потом в отдельном файлике имплементируйте функцию, которая зарегистрирует все нужные вам плагины".

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

Написал однажды, и напишу еще раз.

Самый лучший опенсорс - это опенсорс от больших компаний, который:

* решает побочную для этих компаний задачу, поэтому им нет смысла вот так вот мелко гадить, типа chromium, protobuf, tensorflow, llvm, catboost, etc

* который делается по нормальным корпоративным лекалам, с тестами и KPI

Вышел новый релиз yaQuake, с фиксом падения под musl, как написано в changelog: #vkquake

https://github.com/Novum/vkQuake/releases/tag/1.20.1

========= Quake Initialized =========

execing quake.rc
execing default.cfg
execing config.cfg
couldn't exec autoexec.cfg
3 demo(s) in loop
Playing demo from demo1.dem.


the Necropolis
Using protocol 15
Segmentation fault

Оно, конечно, продолжает падать, всегда, а не как я ранее думал(в некоторых частных случаях).

Видимо, коллегу в idSoftware магии про стек научили, а вот тестировать код - нет.

Завел issue - https://github.com/Novum/vkQuake/issues/508

https://sfconservancy.org/GiveUpGitHub/
https://news.ycombinator.com/item?id=31932250
https://sfconservancy.org/blog/2022/jun/30/give-up-github-launch/
https://lwn.net/Articles/899530

Стоило мне всех позвать на github, как SFC начало всех призывать с гитхаба съехать. #sfc

Говорят, что не будут принимать под свое крыло проекты, которые живут на githab, или не собираются с него мигрировать(что они делают - я не понимаю, и делают что-то вообще, кроме судов - неизвестно).

Они - левые упыри.

https://sfconservancy.org/GiveUpGitHub/

Вы мне можете сколько угодно рассказывать, что мелким шрифтом потом все более развернуто, но первая фраза БОЛДОМ из списка аргументов - "Copilot is a for-profit product".

Жадные MS денег заработали, а в SFC не занесли.

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

"GitHub differs from most of its peers in the FOSS project hosting industry, as GitHub does not even offer any self-hosting FOSS option. Their entire codebase is secret." - ну и чо? В git content addressable storage, там хеши поедут, если они что-нить сделают не так. А в остальном - что такого в проприетарности? Это, в конце-концов, сервис, а не программа.

"GitHub is wholly owned by Microsoft, a company whose executives have historically repeatedly attacked copyleft licensing" - этот аргумент, на мой взгляд, вообще леденящий душу пиздец. Смотреть надо на то, что происходит сейчас.

Ну и такое у меня соображение - SFC, когда чует запах денег, судится. Если не судится - значит, шансов нет.

Еще я не понял, что там с правом на цитирование - типа, совсем небольшой блок кода не считается derived work. Это разве не подходит под copilot?

#xiaomi

https://www.ixbt.com/news/2022/07/01/oled-4k-dolby-vision-xiaomi.html

Кто-то ждет выставок от Apple, а я вот теперь жду Xiaomi. Через 2 дня они представят свои "прошки", и, если доставка будет работать, это будет мой следующий ноутбук.

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

Я родом из славного города Арзамас-16, родины советской атомной бомбы. Родители полжизни проработали на военку, деды вообще были известными в своих областях учеными.

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

Лейтмотивом этих обсуждений было "как бы этот хитрющий Китай не спиздил все наши ценные секретные разработки". Общий консенсус был, что они далеко позади, и им нужны наши технологии.

Прошло 30 лет, у меня и у моих родителей большинство техники - из Китая. Xiaomi, Honor, Huawei, куча ноунейма, продаваемого известными брендами, etc.

Высокие технологии, скоростные поезда - это все не про Рогозина, который хвастается цацками 30-летней давности, а Китай.

Сетевое оборудование, теперь и легковые машины - это все теперь Китай.

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

https://github.com/Novum/vkQuake/issues/508
https://github.com/Novum/vkQuake/commit/1af0e6ae56c09a14589a9990e9574bd195a3cd06

Автор #vkquake, судя по всему, родил нечто, что более-менее решает проблему переполнения стека.

Собственно, проблема прошлого "решения" была в том, что он брал за размер стека треда размер стека main, который сильно больше.

Почему я считаю, что это, все еще, не совсем годное решение?

Потому что:

* Он делит стек на 2 части - static, размером 128к, и dynamic- все остальное. static - это под заранее рассчитанные вызовы рекурсивных функций, dynamic - под выделение данных неизвестного заранее размера.

* Отсюда сразу вытекает баг - если, вдруг, static часть станет > 128к, то на маленьких картах все продолжит работать, а на больших - будет падать.

Ладно, на это пофиг, по крайней мере, не хуже, чем было до этого.

Самая мякотка вот в чем -

  max_thread_stack_alloc_size = (size_t)CLAMP (0ll, (int64_t)stacksize - THREAD_STACK_RESERVATION, MAX_STACK_ALLOC_SIZE);

Короче, у него размер static части 128k, и размер стека под musl - 128k, то есть, размер dynamic части - 0.

Поэтому вот тут - https://github.com/Novum/vkQuake/blob/master/Quake/mem.h#L48 мы всегда попадаем в "slow" path.

7 лет в idSoftware, my ass.

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

UPD: воспользовался своим "правом первой ночи", сделал malloc() всегда - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/quake/1/vk/ix.sh#L36.

Будни #bootstrap

Собирал себе какую-то программулю, обнаружил в выхлопе cmake, что она не может найти libavif, хотя зависимость от нее я поставил.

Уже наученный горьким опытом, я обнаружил, что в libavif нет ${out}/lib/cmake.

(кстати, отвлекусь на другую тему - это, конечно, жесть, что разработчики cmake решили сделать свою систему package discovery. Весь unix пользуется pkg-config(*.pc файлы). И жесть в квадрате - нельзя просто попросить найти libXXX, ее надо попросить или через pkg-config, или через встроенный механизм cmake)

https://github.com/AOMediaCodec/libavif/blob/main/CMakeLists.txt#L528

if(BUILD_SHARED_LIBS OR VCPKG_TARGET_TRIPLET)

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

cmake - это херовый интерпретатор языка, похожего на Basic + M4, и зачем-то люди пишут на нем свои сборочные скрипты. Слишком много дурацкой вариативности.

Я выставил в ON вторую переменную, которая нигде больше не используется - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/avif/ix.sh#L11

А еще я теперь на такие штуки пишу тест, который выполняется прямо в момент сборки - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/avif/ix.sh#L15

После этого шаманства все собралось, как надо.

TIL об https://github.com/posva/catimg

IMHO самая удобная из известных мне программ для просмотра картинок прямо в терминале, не отходя от кассы:

* Не использует богомерзкие sixel

* Использует символы unicode для увеличения разрешения

* Не пытается открыть графическое окно поверх терминала

* Очень компактная. Не пытается реализовать очередную никому не нужную фабрику по загрузке картинок, использует convert из ImageMagick.

* Написана не на перле и баше, а вовсе даже на С.

https://gitlab.gnome.org/GNOME/gtk/-/issues/5004
https://www.phoronix.com/scan.php?page=news_item&px=GTK5-Might-Drop-X11

#gnome

Коллеги рассматривают возможность убрать поддержку X11 из GTK5.

Тикет находится в замороженном состоянии, потому что ссылка на него попала в новости. Поэтому прямо сейчас там ЖЫРА нет, но обязательно будет.

Как ни странно, я тут поддерживаю коллег. X11 никто не пилит, бекенд для него в gtk-gdk уже давно не первого класса.

Поэтому довольно логично в новом коде не поддерживать "загнивающую" технологию. Желающим гонять X11 завсегда остаются более старые версии софта, а если хотите продолжать быть луддитами - ну так, пожалуйста, позиция мейнтейнера Xorg, вроде, открыта.

Гномовцы, конечно, в своем стиле:

"If the "handful of environments" cover 90% of the user base, I would not talk about "massive narrowing" as much as a reallocation of the efforts of a volunteer-driven project."

А ничо, что главный разработчик GTK, Matthias Clasen, он делает примерно 40% коммитов в GTK, работает full time на Red Hat?