Каково назначение Snap для Linux?

Традиционное управление пакетами в Linux имеет множество преимуществ. Зависимости могут быть общими, что делает вещи небольшими и эффективными. Как правило, они проходят через какой-то комитет, и, таким образом, несколько глаз (различаются между дистрибутивами Linux, в некоторых из них меньше процесса, чем в других ). Обычно также есть центральное место для регистрации ошибок.

Однако традиционное управление пакетами имеет некоторые недостатки.

Например, когда вы выпускаете новую версию libfoo, буквально все, кто использует дистрибутив, получают эту новую версию.Это означает, что сопровождающие дистрибутива должны быть невероятно осторожны при отправке обновлений. Они не могут регрессировать.

Кроме того, довольно редко можно увидеть, как вышестоящий разработчик приложения выполняет работу по упаковке своего приложения для различных дистрибутивов Linux. Особенно когда они понимают, что не смогут выпускать свои обновления так легко, как ожидали. Например, в Ubuntu после того, как стабильная версия будет вырезана, новые функции, как правило, не разрешается добавлять в программное обеспечение в дистрибутиве. Только исправления безопасности и исправления ошибок. И даже этот процесс тяжел . Вот почему Ubuntu остается стабильной, но также и то, как архив Ubuntu устаревает в течение всего срока службы выпуска.

Еще одна проблема (это недостаток или преимущество, в зависимости от того, как вы на это смотрите ):обычно, чтобы включить программное обеспечение в дистрибутив Linux, оно должно быть с открытым исходным кодом. Не все есть.

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

Снэпы — это также просто изображения в формате squashfs, которые содержат… вещи. Лицензионных ограничений нет. Это позволяет Microsoft быстро выпустить Skype.или Spotify, чтобы выпустить свой плеер.

В результате того, что они связывают зависимости и представляют собой просто образ squashfs, их довольно легко установить и запустить в любом дистрибутиве Linux, независимо от встроенной -системы управления пакетами этого дистрибутива.

Will new applications eventually migrate to Apt (or other Linux package management systems), or will Linux users have to run two different package managers to get all the applications they want?

Да, традиционные системы управления зависимостями никуда не денутся. Новое программное обеспечение со временем будет доступно через apt. Но это по-прежнему будет делаться членами сообщества, которые просто хотят, чтобы программное обеспечение было в apt, а не самими разработчиками основной ветки разработки. И в зависимости от того, как работает ваш дистрибутив Linux, это программное обеспечение может со временем устареть, пока вы не обновитесь до следующего. Вообще говоря, если вам нужны новейшие вещи, вам нужно получить их от разработчиков основной ветки разработки. Как вы заметили, похоже, они все больше и больше выбирают снэпы для этого. Еще одним вариантом являются PPA (или аналогичные ).

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