В света на технологиите има стара шега, че всеки път, когато някой се опита да създаде формат, който обединява най-доброто от всички останали, за да се избегне разсейването, единственото нещо, което правят, е да добави нов към списъка. Има някои от тях с усилията за създаване на формат на пакета, който може да работи на всички дистрибуции на Linux без промяна. Досега този век вече сме били трима.
Snap, Flatpak и Appimage. Разлики с традиционните формати
Основната разлика между родните формати на пакети и самостоятелните формати на пакети е, че първите споделят зависимости с други програми, инсталирани на операционната система. С други думи, ако програма Y се нуждае от зависимост 1 и тази зависимост е инсталирана от програма X, която също се нуждае от нея, тази зависимост няма да бъде инсталирана отново.
Програмите, пакетирани в отделни формати, включват всички зависимости, от които се нуждаят, за да функционират. С други думи, зависимост 1 ще се инсталира всеки път, когато се инсталира програма, която се нуждае от нея.
Втората разлика е, че традиционните формати на пакети трябва да бъдат изградени със спецификациите на всяка дистрибуция.. Ето защо, въпреки че Ubuntu е дистрибуция, получена от Debian, разликите са достатъчно важни, че хранилищата на първата не могат да се използват във втората.
Третата разлика е, че всяка модификация на зависимост от традиционните пакети може да повлияе на работата на всички останали, които се нуждаят от нея. От друга страна, модификациите на програма в независим формат няма да засегнат останалата част от системата.
В зависимост от особеностите на всяка дистрибуция е възможно да инсталирате приложенията в независими формати от мениджъра на пакети и да автоматизирате тяхното актуализиране с мениджъра, който отговаря за тях.
В Ubuntu Софтуерният център ви позволява да инсталирате двете програми в традиционни формати като Snap, като отдава предпочитание на последните. Въпреки че има плъгин, който позволява софтуерния център на GNOME (от който произлиза Ubuntu), той не работи с тази дистрибуция.
В случая на Ubuntu Studio е възможно да активирате опцията за използване на Snap пакети, докато KDE Neon и Manjaro могат да работят и с двата формата.
Щракване
Това е най-новият от независимите формати, тъй като разработката му започна през 2014 г. Той е предназначен не само за дистрибуции на настолни Linux, но също така и за Интернет на нещата, мобилни устройства и сървъри. ДА СЕВъпреки че е възможно да се създадат самостоятелни магазини за приложения, в момента има само един, управляван от Canonical, Snapcraft.
Въпреки че Snapcraft има асортимент от най-популярните приложения с отворен код, Неговата сила са програмите, разработени от частни разработчици на софтуер и доставчици на облачни услуги.
Flatpak
Въпреки че Flatpak стартира официално през 2015 г., това е продължение на друг проект за универсален формат, известен като xdg-app. Този проект се роди с цел да можете да стартирате приложения в сигурна виртуална пясъчник, която не изисква root права или представлява заплаха за сигурността на системата.
Flatpak е фокусиран върху настолни дистрибуции, също така използва концепцията за съхранение на приложения Flathub най-известният.
Силната страна на Flathub е това обикновено има най-актуалните версии на основните приложения с отворен код.
Appimage
AppImage е най-старият от самостоятелните формати на пакети, тъй като беше пуснат за първи път през 2004 г.
Това беше първият формат, който следваше парадигмата на „Едно приложение - един файл“. Това означава, че всеки път, когато изтегляме файл на Appimage, ние изтегляме приложението и всичко необходимо за функционирането му. Ако искаме да използваме приложението, просто трябва да му дадем разрешения за изпълнение и да щракнем двукратно върху иконата, която го идентифицира.
Appimage не използва системата на магазина за приложения, но, сено уеб страница в който можем да намерим списък с всички налични заглавия.
За да актуализираме Appimage, можем да използваме този инструмент.
Липсва ми, че не се споменава за изключително нарастващата бавност на щракване при инсталиране на приложения, защото се нуждае от виртуална единица за всяко едно.
Липсва ми, че не се споменава за изключително нарастващата бавност на щракване при инсталиране на приложения, защото се нуждае от виртуална единица за всяко едно.
Благодаря за вашия коментар. Ще го имам предвид.
Лично аз мисля, че проблемите на независимата софтуерна опаковка не са нищо повече от отражение на много по-дълбок конфликт, който е свързан със степента на съответствие на стандартите LSB и FSH от различните дистрибуции.
Една от основите зад опаковката е внедряването на стандартни библиотеки, като се запазват както мястото, така и местоположението на софтуера, както и конфигурационните файлове. По този начин се избягват библиотечни конфликти. Нещо, което е често срещано в други операционни системи и което за съжаление, като не спазва стандартите, в крайна сметка затруднява поддръжката и актуализирането на софтуера, камо ли миграцията на софтуер от една дистрибуция в друга. Лошата практика на ръчните компилации, изпълнявани многократно от инструкции, без да се анализира спазването на стандартите при нейното изпълнение, се оказва огромно главоболие за системните администратори. Особено когато някой трябва да поеме производствен сървър, инсталиран от друг предишен администратор.
Независимата опаковка, по един или друг начин, в крайна сметка допринася за тази философия, насърчавайки повече от независимост, зависимост от определен формат или компания. Многократно превръщането на миграцията на платформа в почти невъзможна задача. Мислене повече в краткосрочен план, отколкото в дългосрочен план. Ситуация, на която може да стане свидетел всеки сериозен администратор, който има повече от 15 години опит. И казвам тази цифра нарочно, тъй като в този период щеше да се случи достатъчно разпространение, за да осъзнаем, че рано или късно проектите или услугите ще бъдат принудени по една или друга причина да мигрират от платформа. Ситуация, която рядко влиза в процесите на оценка по време на изпълнението на даден проект. Там, където най-лесно се мигрират, са именно платформите, които най-добре отговарят на гореспоменатите стандарти. Като тези независими опаковки, тези, които са най-отдалечени от тези стандарти.
Интересен принос, не ми беше хрумнало да се замисля
Инструментът за актуализиране на файлове AppImage е практически безполезен. От 7 AppImage файла, които съм изпробвал (Inkscape, Olive, KSnip, MuseScore, OpenShot, наред с други), той се е опитал да работи само с един, завършвайки с „Не съществува подпис за проверка“ и следователно не го актуализира. Тоест НЕ СЕ ИЗПОЛЗВА ЗА НИЩО, можете да премахнете препратката. Освен това не е актуализиран от месеци.
Благодаря за коментара