Em breve Snaps serão tão rápidos quanto os métodos tradicionais de empacotamento

Os desenvolvedores da Canonical anunciaram que após verificar o motivo dos aplicativos disponibilizados por Snaps demorarem mais para iniciar, se comparados aos aplicativos providos pelos métodos de empacotamento tradicionais, chegaram a conclusão que o grande problema dos Snaps está no método de compressão adotado: o XZ. Eles esclarecem que inicialmente o XZ foi escolhido por ser suportado por uma vasta gama de versões do kernel Linux, e bem como é o método que entrega pacotes menores visto que um dos objetivos dos Snaps também é entregar software para IoT.

Agora, será possível que os empacotadores de aplicativos em Snap utilizem o método de compressão LZO, que também é amplamente suportado pelas diversas versões existentes do kernel Linux, embora gere um pacote bem maior que o compactado com o método XZ. Ambos os métodos de compressão, XZ e LZO, estarão disponíveis para os empacotadores escolherem qual é a melhor opção considerando o objetivo do aplicativo disponibilizado (se desktop, se IoT, etc).

No entanto, para que vários softwares disponíveis na Snap Store possam iniciar mais rápido, é necessário que o empacotador envie um novo pacote utilizando o método de compressão LZO. Os desenvolvedores do Snap informaram que nenhuma modificação no pacote é feita nos servidores da Canonical, que os Snaps garantem a entrega de bit a bit daquilo que o empacotar enviou (com garantia de que o conteúdo não foi modificado no meio do caminho) e que por isso eles não mexem nos pacotes e no método de compressão escolhido pelo empacotador.

Nos testes, o pacote Snap do aplicativo Chromium, comprimido por LZO, foi iniciado tão rápido quanto o aplicativo sem compressão.

Acredito que é uma boa notícia, embora depois que eu coloquei um SSD não esteja mais sentindo essa lentidão.
Quando ainda usava HD, eu fiz um teste com o Chromium em DEB, Flatpak e Snap, e o resultado que encontrei foi que o pacote Snap estava iniciando mais rápido que o pacote Flatpak e mais lento que o DEB.

Fonte:
https://snapcraft.io/blog/why-lzo-was-chosen-as-the-new-compression-method

Ainda bem que existe linux pra todos os gostos. Não gosto disso aí não.

______________________
https://github.com/phoemur

Tenho um M.2 e o pacote nativo ainda é o mais rápido. Mas bom saber que a Canonical percebeu as deficiências do seu próprio produto e está disposta a melhorá-lo para entregar uma solução de verdade, embora eu duvide que um dia essa solução seja mais performática que um pacote nativo, onde o processo todo ocorre fora de uma sandbox.

Há outros detalhes também fora do escopo de performance, que já foram bem debatidos em outros tópicos, como a integração do software com o restante do ambiente desktop.

Para falar a verdade, não vejo Snaps sendo utilizado fora do mundo Ubuntu. Acredito que talvez, o Ubuntu no futuro entregue apenas o core do seu sistema em .deb (kernel, glibc, etc), enquanto que o ambiente desktop e outros aplicativos serão todos entregues em Snap (o GNOME do Ubuntu 18.04 era todo em Snap).

Em outras distribuições, o Flatpak é mais presente. Porém, ainda é uma opção secundária, os repositórios de terceiros que oferecem pacotes nativos ainda são mais utilizados.

phoemur... Somos dois... Uso Ubuntu mas não uso snaps... Se isso se tornar obrigatório ficarei com Fedora ou Debian

É uma boa noticia para quem usa essa tecnologia. Eu sou outro que prefere compilar o pacote do que encher o sistema de tralha. Nada contra.

___________________________________________________________

Conhecimento não se Leva para o Túmulo.

https://github.com/MauricioFerrari-NovaTrento  

Nada contra. Só não quero pra mim. Kkkkkk

Pra mim o problema de Snaps/Flatpaks/Appimages são esses:

1-) Se for pra empacotar todas as "DLL´s"/ shared libraries em cada pacote repetidamente igual no windows, se for pra rodar cada mínimo aplicativo em um container, então não há motivo pra usar linux no desktop. Pode rodar esses containeres em qualquer outro SO que dá no mesmo.
Não estou nem falando de tamanho dos pacotes, já que armazenamento é barato.

2-) Há vários programas em que o negócio simplesmente não compila direito. Daí você vai falar com o desenvolvedor o cara fala que só tem suporte pra usar o AppImage por exemplo, ao invés de consertar o pacote.
Um exemplo é o Ultimaker Cura, que por quase 6 meses não funcionava do repositório do Debian e nem compilando localmente. Tinha um problema no pacote que só funcionava se você executasse o programa como usuário root.
E a resposta do desenvolvedor era usar o AppImage ao invés de arrumar o pacote.
Via de regra isso acontece com desenvolvedores que vêm do ambiente Windows - ou outros diferentes - e que não tem interesse de fazer as coisas como devem ser feitas em Unix-like.

3-) O mesmo problemas dos PPA´s: Do ponto de vista OpenSource, como você garante que aquele binário distribuído vem do código fonte que foi disponibilizado?
Isso é ainda pior em casos como anterior, em que não dá pra compilar localmente.

______________________
https://github.com/phoemur

Recebi outro laptop da empresa para home office, e este veio com o Mint 20.
Tive que instalar o Robo 3T, via pacote Snap, porque o Mint não tem ferramenta gráfica para abrir base de dados do MongoDB.

Outra coisa que o Mint deixa a desejar é a integração do Google com a interface gráfoca, como Drive, Calendário, Agenda, etc. (contas online).

--------------------------------------------------------------
"Linux: several flavors, one way: - Freedom of choice!"

Concordo em partes. Algo rodando em sandbox sempre vai ter alguma perda de desempenho, mesmo que imperceptível para a maioria dos usuários. Porém sandbox se tornará padrão pela frente. O Wayland, por exemplo, vai isolar as aplicações de tal modo que um aplicativo não consiga saber o que o outro está fazendo.

Sobre a questão dos temas, os pacotes Snap e Flatpak já suportam uma grande variedade de temas, se o usuário usa algum desses temas, os aplicativos Snap e Flatpak usaram o mesmo tema. Além disso, os pacotes desktop-portal permitem integrar os diálogos nativos. No entanto, há desenvolvedores que estão entregando pacotes Snaps e Flatpaks com seus próprios diálogos ao invés de integrar suporte ao desktop-portal, e há desenvolvedores que escolheram entregar aplicativos com sua própria aparência ou tematizados a gosto do desenvolvedor. Isso é escolha do desenvolvedor, não um problema dos pacotes Snap e Flatpak. No entanto, há ainda que melhorar nos temas QT, tanto no Snap quanto no Flatpak.

Sobre Snaps estarem ou não sendo usados em outras distribuições, há a popularidade de alguns deles entre várias distribuições:
https://snapcraft.io/blog/popular-snaps-per-distro-2020-edition
Além disso, cada Snap tem um gráfico individual:
https://snapcraft.io/pycharm-educational

Sobre o futuro do Ubuntu, acredito mesmo que seja em Snap ou uma tecnologia que venha a substituí-lo. E não vai sobrar nenhum DEB não, visto que o core do sistema pode ser entregue e gerenciado pelo OS-Tree.

Os Snaps estão dando segurança aos desenvolvedores para a distribuição de software no Linux. Os principais publicadores de aplicativos na Snap Store, além da própria Canonical, são: Microsoft, Mozilla, Google, Spotify, Jetbrains, KDE, entre outros.

Acho que a Snap Store tem que melhorar muito ainda: internacionalização das descrições, apresentar mais capturas de telas, opiniões de usuários, vídeos, exigir que os desenvolvedores verifiquem suas identidades, exigir que os desenvolvedores melhorem as descrições de seus programas, melhores informações sobre as licenças. Mas acredito que está no caminho certo.


Mais estatísticas sobre Snaps podem ser vistos aqui:
https://snapstats.org/

1) sua argumentação não faz nenhum sentido. Primeiro que as "DLL's" são compartilhadas também, há um sistema base e alguns pacotes adicionais que vão entregar bibliotecas, se você instalou o Kdenlive e depois resolveu instalar o Kate não será necessário baixar as bibliotecas do KDE por duas vezes, visto que há compartilhamento de bibliotecas (há um Snap exclusivo que adiciona bibliotecas do KDE e que será usado por todos os Snaps que precisem de bibliotecas do KDE para rodar. Em casos que os chamados "plugins" não estão disponíveis, aí sim o desenvolvedor deve empacotar a dependência junto com o programa, mas existem muitos plugins: QT, KDE, Gnome, GTK, Python, Electrum, Flutter, Java, Wine, Ruby, Rust, Go e mais. Segundo, os contêineres são o futuro e estarão presentes nos desktops, um dos motivos para o surgimento do Wayland em substituição ao X é exatamente esta questão de isolamento dos aplicativos. Aliás, Gnome e KDE estão fazendo bastante esforços para melhorar o desktop-portal, que é uma espécie de isolamento também (ao invés do aplicativo ter acesso aos arquivos, é o desktop-portal que faz a ponte entre os arquivos e o aplicativo, garantindo que o aplicativo consiga somente acesso ao arquivo que foi escolhido pelo usuário.
2) justamente pela zona que é o mundo Linux vários desenvolvedores escolheram não dar suporte a nada, alguns só entregam o código-fonte. Snaps e Flatpak estão aí para resolver essa zona. Os desenvolvedores podem fazer um único pacote e entregar aplicativos para diversas distribuições Linux sem muitos esforços. Para compilar um aplicativo é simples, basta ter um ambiente Linux idêntico ao usado pelo desenvolvedor (Snaps e Flatpak consertam isso, pois você sempre terá o ambiente que o desenvolvedor usou).
3) Snaps e Flatpak requerem que você confie no desenvolvedor, assim como você já faz quando usa Windows. Existem sistemas de construções automáticas para Snaps e Flatpaks, bastando o desenvolvedor postar o código fonte no Github e um robô faz a compilação, entregando o pacote resultante. Há inclusive distribuições Linux cujos desenvolvedores entregam cerca de 50.000 pacotes sendo a maioria empacotado por robôs (como é que vocês acham que o NixOS consegue entregar tantos pacotes quanto o Ubuntu com menor mão de obra?). Não sei sobre os Flatpaks, mas Snaps tem a garantia de que o pacote entregue pelo desenvolvedor na Snap Store será bit a bit idêntico ao pacote instalado no seu sistema.