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

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