WTF в XFCE

glycin

gnom -овское что-то, ещё и на rust. Нафейхоа оно нужно? Удаляй.
А вообще на топорную слежку смахивает

Ага, а bwrap это для создания изолированных кусков фс. И разумеется всё это какой то очень стрёмный мусор, но блин, с обновлением арча кажется прилетело.

Осталось понять что его запускает (не сами же процессы вроде dolpin и xfdesktop их на себя вешают!) и как удалить.

Пора ставить кеды или lxqt.

Да, это что-то ненужное. Прилетел, как зависимость для gdk-pixbuf2 и с тех пор обновлялся несколько раз:

$ grep -E '\sglycin\s' /var/log/pacman.log | tail -5            
[2025-09-23T09:07:07+0300] [ALPM] installed glycin (2.0.0-4)
[2025-09-26T21:02:54+0300] [ALPM] upgraded glycin (2.0.0-4 -> 2.0.0-5)
[2025-09-27T21:38:26+0300] [ALPM] upgraded glycin (2.0.0-5 -> 2.0.2-1)
[2025-10-03T20:38:40+0300] [ALPM] upgraded glycin (2.0.2-1 -> 2.0.2-2)
[2025-10-10T12:16:48+0300] [ALPM] upgraded glycin (2.0.2-2 -> 2.0.3-1)

Может его того, sudo pacman -Rdd ?

Upd. Попробовал, крыса не завелась, установил заново.

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

Тремя процессами, висящими ещё 10 секунд после загрузки картинки? Принудительно прилепляя свои копии к чужим процессам, хз чем это может грозить? Кажется маразм заиграл новыми красками. Можно же было прогнать антивирусом все значки в пакетах репы.

Раньше у тебя либа gdk-pixbuf2 сама декодировала картинки, а теперь делает это через запуск прослойки в изолированом окружении.

Б - безопасность, о которой мы не просили.

Да, Гном, в моих джипегах с камеры, где я фотографирую кота и еду, непременно надо подозревать вирус.

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

Какой шиз это придумал, совсем крыша отъехала у людей?

Какой шиз это придумал

Кто придумал допускать ошибки в декодерах, через которые можно RCE делать или процесс ронять? Ну хз вообще, я тоже осуждаю такое.

процессами, висящими ещё 10 секунд после загрузки картинки?

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

Можно же было прогнать антивирусом все значки в пакетах репы.

И антивирус, конечно же найдёт особо скрафченные картинки, которые ты как-то случайно из интернета сохранил, а потом в Проводнике в директорию с ними зашёл? Это где существует антивирус, который все zero-day знает заранее? Хочу себе такой.

У меня этот глицын однажды всю память сожрал, даже oom-killer не помог.

https://gnome.pages.gitlab.gnome.org/glycin/ - жесть какая. А 30 лет назад Rasterman с одной imlib делал всё на порядок быстрее и проще. И больше. Да когда они перестанут переписывать одно и то же??????

rust
всю память сожрал

У меня такое только с go было, но что-то я задумался... Модно-молодёжно — и всю память сожрал.

Помню, что он в топе был, перед тем, как комп окончательно завис. Но, может, ещё и распухший clangd виноват был:)

Лично у меня возникает два основных вопроса.

1. есть ли такое в KDE

2. если есть, то как это удалить под корень

Да какие особо скрафченые? Речь об интерфейсных. Наборы иконок, миниатюры окон, обои стола как максимум, но всё! 99,9% от разработчиков дистра. Файлменеджер сам в состоянии вынести декод миниатюр в отдельный поток и даже спросить во сколько потоков. В дельфине уже 10 лет как. А тут лучше бы озаботились этим вопросом не для иконок системного меню а для браузеров.

Надо вспомнить обратную сторону. Вот мы берём слабое железо и/или недостаток памяти и разумеется занятый диск. Представляешь как оно лагать будет на ровном месте в ожидании пока что то свопнется чтобы планировщик мог высвободить память для форка процесса, который потом станет декодировщиком картинок?

В крайне разумном виде - для миниатюр файлов в дельфине и прочем софте, который захочет дёрнуть пакеты миниатюр через kio. Да, миниатюры появляются с задержкой и иногда даже с факапами, но стабильность очень даже на высоте. И там 1 процесс а не нашествие зерлингов.

А как посмотреть эти процессы? У меня их или не возникает или я не там смотрю (фильтр процессов в htop).

Только, когда в ristretto открываю картинку.

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

Я их в htop увидел. Сначала грешил xfdashboard какие то хаки использует, оказалось не он.

Возможно это происходит если у панели есть фоновое изображение, у меня его нет, поэтому и не дергаются glycin-loaders и bwrap

Да какие особо скрафченые? Речь об интерфейсных.

Простые просмотрщики картинок вроде превью в файловом менеджере или отдельных приложениях используют те же функции GDK, что и загрузчик иконок для интерфейса. У этих функций нет возможности узнать, безопасна картинка или нет. Так что если хочется защититься от 0.1% опасного контента, придётся защищаться от всего.

Файлменеджер сам в состоянии вынести декод миниатюр в отдельный поток и даже спросить во сколько потоков.

Речь не про отдельный поток, а про отдельный процесс. Если поток внутри процесса сделает что-то не то, падает весь процесс. Если картинка вызовет RCE, у атакующего считай есть шел у тебя на компе. Но если дочерний процесс упадёт, у тебя просто не будет части картинок. Если RCE случится внутри процесса в песочнице, у атакующего будет шел внутри песочницы, где доступа к твоим файлам нет.

А тут лучше бы озаботились этим вопросом не для иконок системного меню а для браузеров.

А браузеры уже давно используют песочницы, чтобы было сложнее эксплуатировать уязвимости. Firefox где-то лет 10, с 2015, как только начали на многопроцессную архитектуру переходить. В Chrome песочницами заниматься стали ещё раньше.

Надо вспомнить обратную сторону. Вот мы берём слабое железо и/или недостаток памяти и разумеется занятый диск.

Hey, you! You are finally awake.
Вот это ты проспал всё. Проблема с загрузкой картинок с диска была дикая. Меню тормозило на секунды. Проблема как таковая никуда не делась, но её не видно из-за повсеместного использования SSD. Возможно, всё стало даже ещё хуже. Но у меня вот теперь даже проблема воспроизвести проблему, потому что в ноут не получится вставить HDD.

Представляешь как оно лагать будет на ровном месте в ожидании пока что то свопнется чтобы планировщик мог высвободить память для форка процесса, который потом станет декодировщиком картинок?

Я понимаю твой посыл, но твои аргументы слабые. В частности, если у тебя ситуация такова, что выделение любого количества ОЗУ под что-либо требует свопа, ты уже в жопе, потому что для собственно картинок тоже нужно ОЗУ. Возможно, даже больше, чем займёт процесс.

Форк обычно работает не так, как ты описал. Если, скажем, у тебя процесс, который в общей сложности занимает гигабайт ОЗУ, его форк как бы тоже будет занимать гигабайт, но вот общее потребление ОЗУ от его создания увеличится далеко не на гигабайт. Реально дополнительное ОЗУ начнёт использоваться только когда копия процесса начнёт что-то в своём адресном пространстве менять. Обычно после форка ребёнок не делает ничего кроме execve, так что запуск нового процесса из-под гигабайтного родителя не займёт дополнительный гигабайт.

Самое забавное тут то, что ты не заметил главную проблему этого glycin’а.

Простая прозрачность и обои. Возможно дело в Арче, помешанном на обновлениях.

0.1% опасного контента?! 0,00000000000001% может быть... Причём с вероятностью в 99,99% уязвимость реализуется в виде сегфолта а не исполнения кода, а как взлом файлменеджера или панели должен привести к утечке данных?

И потом, если посмотреть на kio или ffmpegthumbnaler 10-и летней давности то этот глицин выглядит так как будто его я делал и даже не особо старался при этом.

Речь не про отдельный поток, а про отдельный процесс.

Я имел в виду процесс. КДЕ давно изолирует всё по процесам и чего там сильно не хватает - многопоточности создания миниатюр. Было бы проще всего реализовать это многопроцессностью, пусть всего 2 вместо 1.

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

Т.е. там можно держать декодеры картинок в одной песочнице с кодом авторизации и банковскими картами, а вот обои рабочего стола и иконки в меню ни-ни!

Проблема с загрузкой картинок с диска была дикая. Меню тормозило на секунды.

Это когда? В гномовайланде на hdd что ли? Ну верю, эти могли. Но у остальных всё это время всё работало хорошо. К тому же у меня даже не hdd, у меня местами микроСД с работой строго в 1 поток и если она занята крупным пакетом то весь мир подождёт. Но... Дельфин+кио, картинки подтягиваются в фоне. И то, я нигде не видел прям проблемы, лишь задержки без сильных фризов. Приложения гтк 2 и 3 делали всё в 1 процесс и поток и вполне себе прилично, ещё и не падая если библиотека декодера выдавала сбой 9а нет ли там какой то внутрипроцессной изоляции?).

что выделение любого количества ОЗУ под что-либо требует свопа, ты уже в жопе,

Не, это значит что всё что требует будет фризить, а всё что не требует - будет идти плавно как будто никакого недостатка нету. Это в промежутке действия zswap, где то между 100% и 150-200% использования ОЗУ. Например тот же браузер - при создании вкладки и порождении процесса он тормозит, пока идёт выделение памяти на её отрисовку тормозит, а когда память выделена всё ОК даже если другие вкладки и фоновая нагрузка что то там делают.

потому что для собственно картинок тоже нужно ОЗУ. Возможно, даже больше, чем займёт процесс.

Проблема не в том что картинке нужно ОЗУ, проблема в трешинге когда нужно запустить процесс, библиотеки и конфиги которого ыфтеснены из кеша. Если это один жирный бинарник то не страшно - операция то по сути одна. А вот если на копеечное действие надо 2-3-4 раза свопнуть память, прочитать туда файл, свопнуть память, запустить туда процесс, дропнуть кеши и тут же перечитать их заново, а паралельно с этим другие процессы поднимают из свопа свою память - тут уже планировщики не справляются и эффективность резко падает.

Самое забавное тут то, что ты не заметил главную проблему этого glycin’а.

А в чём она? Я действительно мало что заметил на фоне общего арчебардака, из за которого ноут с самым быстрым из имеющихся у меня в наличии процессоров занимается только тем что качает ролики с ютуба, но даже не может их воспроизвести потому что я впервые увидел vlc с недоступными кодеками mpeg2, alac, h264 10bit и нерабочим звуком потому что 3 звуковых подсистемы конфликтуют и софт не знает куда цепляться.

Даже в Void такого нет, а тут xfce самое свежее
Иди к нам, bro

Если картинка вызовет RCE

Не с любой же «картинкой» так можно, но я так понял это игнорируется и всё что может быть обработано там, туда и отправляется :(

Тоже с этим столкнулся.
Вышло обновление одного из WM, которые у меня установлены. Скачал релиз с GitHub, установил.
Сам WM работает, а программы не запускаются. Начал разбираться.
При запуске программы через «горячие» клавиши — ничего не происходит.
При запуске программы из dmenu — ничего не происходит.
При запуске из терминала — ничего не происходит.
Программа не запускается, ошибок/предупреждений нет, но что странно и необычно — освобождается терминал; то есть, не нужно жать Ctrl-C чтобы завершить программу и закрыть терминал.

Открыл htop и стал наблюдать. Оказалось, что программы запускаются, а вот их окна так и не появляются.
Ещё одна странность — они с трудом «убиваются» через F9 в htop или killall или не убиваются совсем.
Заметил в самом низу дерева процессов принадлежащих запускаемой программе (ниже родительского и всех дочерних) процесс с именем bwrap и огромным числом ключей и параметров. И вот после «убийства» этого процесса внезапно и мгновенно открылось окно незапускавшейся программы.

Всё это походило на вирус. Проблемными программами были как минимум GTK2-версии leafpad и PCManFM. Firefox, вроде запускался, но это не так важно. Вариант «тут работает, тут не работает» мне не понравился. Проблема воспроизвелась в двух из пяти установленных у меня WM.

Продолжил разбираться уже с помощью интернета.
Откуда же пошло «заражение»?..
Я помнил, что незадолго до этого установилось нечто с именем glycin и его зависимость bubblewrap, которые внезапно стали жёсткими зависимостями для пакета gdk-pixbuf2.
Забавно, что поиск вывел меня на форум моего же дистрибутива (Artix). Там уже были найдены костыльные решения и я начал пробовать.
Сначала сделал downgrade пакета gdk-pixbuf2 до версии gdk-pixbuf2-2.42.12 (та, у которой ещё не было в зависимостях glycin) и «О, чудо!» — всё резко починилось и заработало как надо. Только собрался поставить в конфиге pacman запрет на обновление gdk-pixbuf2-2.42.12 как случайно заметил что «сломались» темы и иконки. Всё откатилось к простецкой «заглушке» с жёлтенькими папочками и блёкленькими иконками (забыл как тема называется). Почему-то осталась неповреждённой тема Arc. Я иконки хоть и нечасто вижу, в PCManFM в основном, но как-то всё равно напрягало.
По советам с форума выполнил несколько команд:
gdk-pixbuf-query-loaders --update-cache не помогла,
update-mime-database /usr/share/mime не помогла,
pacman -S --overwrite '*' libpng librsvg cairo pixman gtk3 hicolor-icon-theme shared-mime-info adwaita-icon-theme libx11 libxcb кажется, тоже не помогла (ArchWiki очень не рекомендует делать --overwrite).

На форумах люди были возмущены, раздражены, проклинали «гномосеков», Rust и т.д.
Нашёлся и человек сделавший полезное дело.
Довольно быстро в AUR появилась версия gdk-pixbuf2 без glycin.
Называется gdk-pixbuf2-noglycin.
Я установил её (притащилось 27 зависимостей для сборки, всё заняло около минуты — «проклятый дидовский» C «виноват»), всё было нормально; зачем-то снова сделал pacman -S --overwrite '*' libpng librsvg cairo pixman gtk3 hicolor-icon-theme shared-mime-info adwaita-icon-theme libx11 libxcb — сломались иконки; переустановил gdk-pixbuf2-noglycin — починилось. В общем, выяснилось, что иконки и темы ломаются из-за librsvg, у которой в зависимостях gdk-pixbuf2. То есть, можно было попробовать сделать downgrade librsvg, но не понадобилось.
На следующее утро я проверил тему на форуме и уже была готова версия librsvg без glycin.
Называется librsvg-noglycin. Есть в AUR у кого Arch и в Omniverse у кого Artix.
Собиралась и устанавливалась целую вечность с безумным количеством сборочных зависимостей (55 пакетов по сборочным зависимостям, over 13000 файлов в ../.cargo «весом» почти в 150 Mb, заняло примерно 15 минут; «прогрессивный» Rust как ни крути; что тебе не нравится, пёс), но, вроде бы, всё получилось.
Для меня ситуация развивалась в режиме реального времени. Пока всё работает хорошо. Как собственно и работало до этого безумия с glycin.
Писал по памяти, прошло уже девять недель, эти два пакета уже несколько раз обновились и возможно что-то по мелочи напутал.
Может кому поможет кто столкнётся с этой напастью.

TL;DR
Рассказ о моих злоключениях в комментариях выше можно не читать, но для тех для кого проблема до сих пор актуальна альтернативой будут два пакета из AUR для тех у кого Arch (или Omniverse для тех у кого Artix): gdk-pixbuf2-noglycin и librsvg-noglycin.
То есть, либо поражённые чумой мейнстримные «оригиналы», либо «вылеченные» пакеты из AUR/Omniverse с потенциальными проблемами.
Я пока выбрал второе, хоть и стараюсь из AUR/Omniverse ничего не устанавливать обычно. В общем, на свой страх и риск.
Из-за Rust сборка вообще превращается в @#$дский цирк, но бинарных пакетов нет.
Как это делается в более других дистрибутивах я не знаю.

Всех кто отметился под этим постом тегать не хочется, но возможно будет актуально для: kirill_rrr dmitry237 James_Holden

Спасибо

Однако, креативность гномосеков в том как всё испортить на ровном месте неиссякаема.

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

Да не то слово!
В уходящем году именно этот инцидент заставил меня в очередной раз задуматься: «если так дальше пойдёт, то куда валить с Linux».
И вариантов не то что бы в изобилии. :-(

Пора ставить кеды

KdeUserFeedback уже выпилили аттедава? Если нет, то ненужно.

https://0x0.st/P-Zr.png