KDE Plasma 6.7 меня чуть-чуть подбешивает своими багами, и я ОЧЕНЬ надеюсь, что кдешники выпустят патч.
Меня уже бесит каждый раз отключать виртуальную клавиатуру плазмы и получать краши дискавера в лицо после этой обновы...
—————————————————
...сказал бы я, если бы не забыл обновить свою систему. Извиняюсь, вышел патч, беру свои слова назад.
Меня уже бесит каждый раз отключать виртуальную клавиатуру плазмы и получать краши дискавера в лицо после этой обновы...
—————————————————
...сказал бы я, если бы не забыл обновить свою систему. Извиняюсь, вышел патч, беру свои слова назад.
Linux / Линукс
Linux / Линукс 🥸
Ну да, а чё вы ноете? У каждого как минимум есть интегрированная графика старше 2011 года (спойлер: вейланд нормально работает даже на софтвейрном рендере)
Relative ✧
Чёёёёёёё, это сегодня такое качество раннеров на GitHub Actions?
Итого, было 30 таймаутов, и образ собрался за 20 минут, когда в обычном режиме у меня тот же образ собирается 5 минут
Relative ✧
База про такой тип систем
Я не знаю, стоит ли делать пост про настройку дедупликации в btrfs со сжатием?
Очень полезная тема на атомарных/иммутабельных системах, потому что она экономит кучу места от рантаймов, вайн библиотек, бандлов и прочего, что дублируется или частично одинаковое
Очень полезная тема на атомарных/иммутабельных системах, потому что она экономит кучу места от рантаймов, вайн библиотек, бандлов и прочего, что дублируется или частично одинаковое
Relative ✧
Я не знаю, стоит ли делать пост про настройку дедупликации в btrfs со сжатием? Очень полезная тема на атомарных/иммутабельных системах, потому что она экономит кучу места от рантаймов, вайн библиотек, бандлов и прочего, что дублируется или частично одинаковое
Большинство на предыдущий вопрос ответило "да". Ну раз так, держите.
На атомарках/иммутабельных дистрах (Silverblue, Kinoite, openSUSE Aeon, Bazzite и ко) место на диске исчезает гораздо быстрее, и дело не столько в самой системе, сколько в том, что её засирает:
- несколько версий одних и тех же флатпаковых рантаймов;
- слои контейнеров с одинаковой базой;
- wine и протоновые префиксы с сотнями одинаковых дллок;
- appimage, которые с союой тащат внутри копии библиотек.
Вот они – данные, которые идентичны друг другу, но лежат в разных руках и во множественных экземплярах, непорядок. Тут как раз и пригодится делупликация.
Момент только в том, что в btrfs она не встроена, как в той же ZFS. Btrfs даёт лишь системный вызов для сравнения и склейки блоков, а искать дубликаты должен внешний демон. (и да, дедуп прекрасно работает вместе со сжатием, можно сжимать zstd и дедуплицировать поверх, нужные тулзы это умеют)
Из вариантов:
bees - демон, который крутится и подхватывает новые дубли почти сразу после записи. Хештейбл довольно компактный (около 1 гига на 10 терабайт уникальных данных), ну и память не растёт вместе с диском.
Второй варик - duperemove, для разовых прогонов по конкретным папкам, с кэшем хэшей для ускорения повторных запусков.
В ходе моих раскопок я узнал, что в баззите стоит именно bees. Раньше там был самопис под вайн префиксы, потом они в конце 2025 добавили bees, а потом и вовсе отказались от старого сервиса в его пользу, думаю, очевидно, по какой причине.
Вся эта петрушка ставится примерно так (на примере мутабельной системы):
git clone https://github.com/Zygo/bees
cd bees && make && sudo make install
sudo btrfs filesystem show
sudo systemctl enable --now beesd@<UUID>.service
Один нюанс: дедуп по рефлинкам работает только внутри одного дерева субтома. Если контейнеры и флатпак вынесеня по разным субтомам с разными точками монтирования - между ними дедупа не будет, так что стоит проверить заранее через btrfs subvolume list /.
По отзывам юзверей (реддит, дискасс и т д), на тачках с билд-артефактами и репозиториями экономия доходила примерно до четверти занятого места. На протон префиксах это тоже заметно, а вот глядя на сами игры разница почти нулевая.
Сжатие – отдельная история, оно встроено в бтрфс и включается через опцию монтирования: compress=zstd:3 в /etc/fstab или сразу при монтировании.
zstd почти всегда лучший выбор, потому что жмёт сильнее lzo, а по скорости почти не проигрывает. Уровень можно не трогать, дефолтный 3 будет золотой серединой. На атомарках опцию обычно прописывают в конфиге бутлоадера или через инструменты дистра (например, в баззите и Silverblue zstd включён по умолчанию из коробки).
После этих махинаций места под игрулечки и прочий мусор должно стать больше.
Всем добра <3
На атомарках/иммутабельных дистрах (Silverblue, Kinoite, openSUSE Aeon, Bazzite и ко) место на диске исчезает гораздо быстрее, и дело не столько в самой системе, сколько в том, что её засирает:
- несколько версий одних и тех же флатпаковых рантаймов;
- слои контейнеров с одинаковой базой;
- wine и протоновые префиксы с сотнями одинаковых дллок;
- appimage, которые с союой тащат внутри копии библиотек.
Вот они – данные, которые идентичны друг другу, но лежат в разных руках и во множественных экземплярах, непорядок. Тут как раз и пригодится делупликация.
Момент только в том, что в btrfs она не встроена, как в той же ZFS. Btrfs даёт лишь системный вызов для сравнения и склейки блоков, а искать дубликаты должен внешний демон. (и да, дедуп прекрасно работает вместе со сжатием, можно сжимать zstd и дедуплицировать поверх, нужные тулзы это умеют)
Из вариантов:
bees - демон, который крутится и подхватывает новые дубли почти сразу после записи. Хештейбл довольно компактный (около 1 гига на 10 терабайт уникальных данных), ну и память не растёт вместе с диском.
Второй варик - duperemove, для разовых прогонов по конкретным папкам, с кэшем хэшей для ускорения повторных запусков.
В ходе моих раскопок я узнал, что в баззите стоит именно bees. Раньше там был самопис под вайн префиксы, потом они в конце 2025 добавили bees, а потом и вовсе отказались от старого сервиса в его пользу, думаю, очевидно, по какой причине.
Вся эта петрушка ставится примерно так (на примере мутабельной системы):
git clone https://github.com/Zygo/bees
cd bees && make && sudo make install
sudo btrfs filesystem show
sudo systemctl enable --now beesd@<UUID>.service
Один нюанс: дедуп по рефлинкам работает только внутри одного дерева субтома. Если контейнеры и флатпак вынесеня по разным субтомам с разными точками монтирования - между ними дедупа не будет, так что стоит проверить заранее через btrfs subvolume list /.
По отзывам юзверей (реддит, дискасс и т д), на тачках с билд-артефактами и репозиториями экономия доходила примерно до четверти занятого места. На протон префиксах это тоже заметно, а вот глядя на сами игры разница почти нулевая.
Сжатие – отдельная история, оно встроено в бтрфс и включается через опцию монтирования: compress=zstd:3 в /etc/fstab или сразу при монтировании.
zstd почти всегда лучший выбор, потому что жмёт сильнее lzo, а по скорости почти не проигрывает. Уровень можно не трогать, дефолтный 3 будет золотой серединой. На атомарках опцию обычно прописывают в конфиге бутлоадера или через инструменты дистра (например, в баззите и Silverblue zstd включён по умолчанию из коробки).
После этих махинаций места под игрулечки и прочий мусор должно стать больше.
Всем добра <3