суббота, 16 января 2021 г.

FlatPak, Snap, AppImage и прочие современные веяния

В борьбе с "адом зависимостей" и разношёрстностью дистрибутивов Linux, родились системы, которые призваны унифицировать подход к ПО сквозь все дистрибутивы. Их идея в одном - собрать пакет вместе с необходимыми библиотеками в одной программной капсуле. 
Однако, этот подход имеет два вполне известных изъяна:
- Проблема с безопасностью за счёт использования разных версий библиотек в программных "капсулах" и то, что часть из них может быть устаревшими;
- Резко возрастающие объёмы данных, необходимые для хранения всех дублированных библиотек, используемых различными программами.

Безопасность.
Первую проблему пытаются решить с помощью изоляции в песочнице каждой программы - то есть программа запущенная пользователям может ходить только по конкретным местам типа домашней директории пользователя, не может взаимодействовать с другими программами, а её взлом не может сильно навредить компьютеру. 
Минусы этого подхода также вполне очевидны - пользовательская папка таки доступна, ряд операций программа осуществлять обязана по своему функционалу и общей точкой отказа является подсистема (сам Snap, Flatpak и т.п.). То есть при использовании сильно устаревшей версии библиотеки в составе программы, дыра в безопасности таки будет. 
В то же время это вызывает ряд неудобств пользователям - если у пользователя несколько жёстких дисков и, скажем, дистрибутив монтирует их в media, то доступа к ним у программы просто не будет. Я с таким сталкивался на своём ПК, где 5 жёстких дисков и три операционные системы, две из которых из семейства Linux, а папка home преимущественно состоит из символьных ссылок на другой жёсткий диск (чтобы обеспечить прозрачность работы в разных версиях linux, не дублируя пользовательские библиотеки). В итоге после установки Snap версии Telegram Desktop, я не мог закинуть картинки из папки, т.к. программа не имела доступа через симвользую ссылку на другой диск. 

Объёмы данных
Куда более своеобразной является проблема с объёмом данных, который генерируют подобные системы. На картинке выше показана структура папки var, в которой установлены flatpak и snap. Как видно, один из них занимает более 30 Гб, второй более 7 Гб. Стоит напомнить, что полный комплект OS Linux с KDE, LibreOffice, VLC, Blender, Firefox, Chromium, Vivaldi, Skype, Telegram, Inkscape, Krita, Steam, Kdenlive, OBS, Kmail, Nomacs вполне нормально умещаются на 20Гб разделе жёсткого диска, не выползая за него, даже при том, что поддерживается 3 версии ядра. 
При этом, вот в тех 30+ Гб Flatpak содержится всего несколько небольших программ, которые без фарша весят от силы 0,5 Гб. Всё остальное - это по сути дублированные версии всей операционной системы за исключением ядра. "Рациональность" - это не про них. 

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

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

Также вопросы вызывают сами файловые системы, которые поддерживают дедупликацию. По хорошему из относительно стабильных их всего две - уже упомянутая BTRFS и ZFS. Про первую я уже как-то писал - она вызывает очень много вопросов, как только случается сбой. При этом если у вас была включена дедуплекация - вы никогда не восстановите файлы с поломанной файловой системы (будет каша из кусочков файлов в произвольном порядке, которую никто не разгребёт). А что касается ZFS, то при кажущейся большей надёжности, система во-первых супер-прожёрлива до оперативной памяти (готовы сделать файловую систему потребителем №1 в вашей операционке?) и её качества (настоятельно рекомендуют использовать ECC-корректируему память, т.к. множество небезопасных операций происходит именно в оперативке. А во-вторых она также доставляет трудности при восстановлении данных, широко распространённых открытых инструментов для чего просто не существует.

В итоге, единственным инструментом из всех имеющихся, которым я пользуюсь - остался AppImage. Он хоть и имеет перечисленные недостатки, позволяет сразу оценить масштаб трагедии - сколько будет весить программа по совокупности (а не то, что вам пишут что весит она, скажем 500 Мб, а к ней прилетает база в 11Гб) и позволяет решить вопрос ПО, которое выбилось из цикла поддержки репозиториями вашего дистрибутива нужных версий библиотек.

Как-то так. 

пятница, 8 января 2021 г.

Mac OS X и древние привычки (клепать файлы .DS_Store)

 В отличие от большинства современных операционных систем, OSX Finder хранит настройки отображения папок в создаваемых файлах вида .DS_Store, которые изрядно так бесят, когда взаимодействуешь с другими системами. Чтобы хотя бы заставить систему не писать эти файлы на сетевых хранилищах и USB флешках, необходимо ввести в консоли следующие команды:

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true

defaults write com.apple.desktopservices DSDontWriteUSBStores -bool true 

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