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

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

Ruan
ru4n

(usa Debian)

Enviado em 25/01/2021 - 21:51h

bilufe escreveu:

O Youtube - dl realmente está muito grande. No entanto, há pacotes que chegam a ser menores que os pacotes tradicionais, eu utilizo o pacote Pycharm Community em Snap e ele é ligeiramente menor que o pacote disponível para download no site do programa, e ele ocupa ainda menos espaço em disco graças à compressão dos Snaps.

Não sei o que o empacotador do Youtube - dl em Snap fez exatamente que foi necessário gerar um pacote tão grande, até porque o core só precisa ser baixado uma única vez. Acho que ele colocou toda a estrutura do Python junto do programa, e fico pensando se isso realmente era necessário. Se sim, é uma oportunidade de melhoria para os Snaps. Lembrando que o empacotador do Youtube - dl em Snap é um usuário qualquer, não é o desenvolvedor e nem mesmo da equipe da Canonical. Claro que isso não muda a realidade, do que o pacote é extremamente grande, mas acredito que pode ter havido um erro de empacotamento (ter sido colocado coisas desnecessárias no pacote) é por falta de conhecimento do empacotador. Há outros pacotes Snaps que foram empacotadas por outras pessoas, mas não verifiquei o tamanho (vou fazer isso posteriormente).


Além do Python, o YTD depende também do ffmpeg. Pode ser que o "empacotador" colocou tudo no mesmo snap e disponibilizou por ser mais rápido e fácil.

Deveria ter um critério, talvez um bot que identificasse binários iguais em mais de um pacote durante o envio de snaps, identificando possíveis duplicações e rejeitando o pacote, para que o desenvolvedor corrija e envie novamente. Por exemplo, o ffmpeg já existe em snap:
https://snapcraft.io/ffmpeg

Obviamente, essa identificação deveria usar outros meios além da comparação por nomes de binários. Talvez usando alguma assinatura, ou algo do tipo.

Eu também prefiro utilizar os pacotes nativos, mas em alguns casos recorro a Snaps e Flatpaks por comodismo, principalmente quando estes funcionam bem. Eu acredito não exatamente em Snaps e Flatpak, mas que uma solução para melhorar a vida dos desenvolvedores deve ser adotada, e há sim muita oportunidade de melhorias em Snaps e Flatpaks, e eles estão melhorando. Quem instalou esses pacotes no passado sabe muito bem que houveram evoluções.


Atualmente possuo 14 flatpaks instalados na minha máquina. Uso Debian com backports e multi-arch habilitado (preciso de pacotes i386 para a Steam). Para pacotes nativos, utilizo repositórios de terceiros, como o do vscode, spotify, slack, e google chrome.

Alguns pacotes flatpak que utilizo: GIMP, FileZilla, OpenRA, e o Calibre. Prefiro usar flatpak para softwares que eu não utilizo com muita frequência, justamente para evitar estresse com (possíveis) instabilidades.

mauricio123 escreveu:
O lance é verificar quais pacotes realmente valem a pena usar esses tipos de empacotamento. Tudo isso depende do que o usuário precisa, experiência, etc, pois um usuário com mais experiência, pode achar mais fácil e legal compilar do que ficar esperando um pacote snap ou flatpack baixar.
Volto a reforçar a questão da preferência pessoal.


Sim, cada um escolhe melhor a sua stack de ferramentas, de acordo com a preferência e das necessidades de cada um. Em se tratando de compilação, no meu caso, eu achava muito divertido no inicio quando comecei a usar Linux. Isso durou até eu começar a fazer estágio em uma empresa, onde a variável "tempo" é um problema. E levar 30 minutos ou mais para instalar um programa não é algo que um gerente de projetos gosta de ouvir.

Para o meu workflow atual, não compensa voltar a compilar pacotes. No meu setup atual, não percebi ganhos significativos de desempenho em comparação com pacotes prontos.


  


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

Eric
Grinder

(usa Slackware)

Enviado em 25/01/2021 - 23:54h

Posso estar falando besteira, mas não vejo vantagem no Snap na maioria das distros partindo do princípio que o Snap confronta toda a harmonia da distro estar em shared libs, aí vem esses pacotes estáticos para poder funcionar o software, não falo nem de espaço, mas falo de bagunça mesmo.

Como falaram anteriormente, acho que vai do uso de cada um. Pra mim é muito mais fácil eu gerenciar e criar um SlackBuild do software que eu queira usar do que ficar esperando alguém lançar uma atualização snap e publicar.

Claro além do fato, me baseando em algum software open source, existem várias flags de compilação para ajustar de acordo com a necessidade do usuário. Usando um Snap pelo o que entendi, vc está sujeito a utilizar da forma que o empacotador criou.

Entendo que o Snap veio para facilitar algumas coisas como dependências principalmente, como objetivo o usuário leigo e preguiçoso, porém isso virar padrão? Que vire no Mint e Ubuntu então rsss

- - - - -
www.gitlab.com/grinder
www.github.com/ericfernandesferreira
www.youtube.com/candelabrus1


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

Bilufe
bilufe

(usa KDE Neon)

Enviado em 26/01/2021 - 07:52h

A questão do tamanho dos Snaps vai depender de diversos fatores. O snap do [*****] traz o ffmpeg e também o Python3 e os pacotes python necessários.

Mas nem todos os snaps são enormes, por exemplo, o Snap do OnlyOffice ocupa metade do espaço em disco que é ocupado pelo OnlyOffice em .DEB e Flatpak. O Snap do WPS Office também ocupa menos espaço em disco que o mesmo programa em Flatpak.
Mas há pacotes Flatpak menores que Snaps, e na maioria dos casos os pacotes nativos são menores.

O pacote Snap do Krita tem quase 140 mb, enquanto o pacote Flatpak tem quase 330 mb de tamanho. Já o pacote nativo do Ubuntu 20.04 tem 113 mb + 50 dependências e seria provável que ultrapasse os 140 mb do pacote Snap.




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

Mauricio Ferrari
mauricio123

(usa Slackware)

Enviado em 26/01/2021 - 21:32h

bilufe escreveu:

A questão do tamanho dos Snaps vai depender de diversos fatores. O snap do [*****] traz o ffmpeg e também o Python3 e os pacotes python necessários.

Mas nem todos os snaps são enormes, por exemplo, o Snap do OnlyOffice ocupa metade do espaço em disco que é ocupado pelo OnlyOffice em .DEB e Flatpak. O Snap do WPS Office também ocupa menos espaço em disco que o mesmo programa em Flatpak.
Mas há pacotes Flatpak menores que Snaps, e na maioria dos casos os pacotes nativos são menores.

O pacote Snap do Krita tem quase 140 mb, enquanto o pacote Flatpak tem quase 330 mb de tamanho. Já o pacote nativo do Ubuntu 20.04 tem 113 mb + 50 dependências e seria provável que ultrapasse os 140 mb do pacote Snap.



As dependências geralmente são algumas libs que não costumam passar das casas dos kb, em poucos casos é que podem exceder 1mb. Não quero gente questionando quem compila pacotes no slackware quase toda semana. o padrão é diferente, mas o conhecimento vale para as demais distros.

___________________________________________________________
Conhecimento não se Leva para o Túmulo.
https://github.com/MauricioFerrari-NovaTrento



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

Bilufe
bilufe

(usa KDE Neon)

Enviado em 27/01/2021 - 12:22h

Grinder escreveu:

Posso estar falando besteira, mas não vejo vantagem no Snap na maioria das distros partindo do princípio que o Snap confronta toda a harmonia da distro estar em shared libs, aí vem esses pacotes estáticos para poder funcionar o software, não falo nem de espaço, mas falo de bagunça mesmo.

Como falaram anteriormente, acho que vai do uso de cada um. Pra mim é muito mais fácil eu gerenciar e criar um SlackBuild do software que eu queira usar do que ficar esperando alguém lançar uma atualização snap e publicar.

Claro além do fato, me baseando em algum software open source, existem várias flags de compilação para ajustar de acordo com a necessidade do usuário. Usando um Snap pelo o que entendi, vc está sujeito a utilizar da forma que o empacotador criou.

Entendo que o Snap veio para facilitar algumas coisas como dependências principalmente, como objetivo o usuário leigo e preguiçoso, porém isso virar padrão? Que vire no Mint e Ubuntu então rsss

- - - - -
www.gitlab.com/grinder
www.github.com/ericfernandesferreira
www.youtube.com/candelabrus1


A maior vantagem do Snap / Flatpak é para os desenvolvedores, eles poderão distribuir o software para diversas distribuições sem ter que estudar o sistema de pacotes de cada distribuição, dependências, atualizações, etc. Basta simplesmente empacotar uma vez e mais de 20 distribuições terão o software disponível.

Sobre a questão de shared libs, repito novamente: Snaps e Flatpaks possuem bibliotecas compartilhadas através de snaps "base". Veja aqui:
https://snapcraft.io/docs/base-snaps
Estão disponíveis as bases: core16, core18, core20, core18, bare, solus-runtime-gaming, nix-base, godot-bare, freedesktop-sdk-core-18-08, freedesktop-sdk-runtime-2008
Além disso, os desenvolvedores podem criar suas próprias bases.
Digamos que você instale dois pacotes Snaps que requerem o core20 (Ubuntu 20.04), o core20 será instalado uma única vez e não duas.
Também tem snaps com as bibliotecas do Gnome, bibliotecas QT e outras bibliotecas, sendo que se dois ou mais Snaps requerem tais bibliotecas, elas serão instaladas uma única vez.
Algo similar também ocorre no Flatpak.


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

Sanyu Sukini [山居]
Sanyo

(usa Lubuntu)

Enviado em 27/01/2021 - 14:24h

bilufe escreveu:

Sanyo escreveu:

Oxe, já vi fanboy de Windows, de Ubuntu, de Arch, mas é a primeira vez que vejo um de snap. O cara só fala disso. Parece aqueles adolescentes que descobrem uma banda nova, e querem que todos saibam da sua descoberta.
Acho que se a Canonical largar o desenvolvimento do snap, esse cara tira a própria vida.


Cara, eu sei reconhecer os problemas dos Snaps, mas falo tanto porque há informações que não são verdadeiras. Também uso Flatpak, uso Appimage, Nix Packages e o que tiver.

Sou a favor de inovar. Se os Snaps deixarem de existir vai por algo melhor.

Não parece... Err, inovar, mesmo que a força?


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

Sanyu Sukini [山居]
Sanyo

(usa Lubuntu)

Enviado em 27/01/2021 - 14:30h

Grinder escreveu:

Posso estar falando besteira, mas não vejo vantagem no Snap na maioria das distros partindo do princípio que o Snap confronta toda a harmonia da distro estar em shared libs, aí vem esses pacotes estáticos para poder funcionar o software, não falo nem de espaço, mas falo de bagunça mesmo.

Como falaram anteriormente, acho que vai do uso de cada um. Pra mim é muito mais fácil eu gerenciar e criar um SlackBuild do software que eu queira usar do que ficar esperando alguém lançar uma atualização snap e publicar.

Claro além do fato, me baseando em algum software open source, existem várias flags de compilação para ajustar de acordo com a necessidade do usuário. Usando um Snap pelo o que entendi, vc está sujeito a utilizar da forma que o empacotador criou.

Entendo que o Snap veio para facilitar algumas coisas como dependências principalmente, como objetivo o usuário leigo e preguiçoso, porém isso virar padrão? Que vire no Mint e Ubuntu então rsss

- - - - -
www.gitlab.com/grinder
www.github.com/ericfernandesferreira
www.youtube.com/candelabrus1

Snap faz muito mais sentido em servidores ou mesmo dentro do Ubuntu, já que é a única forma que eles tem de enviar pacotes mais novos, sem ter o problema de quebra de dependências. Claro que isso não exime o snap de trazer outros novos problemas a plataforma.
A realidade vivida pelo Ubuntu não é a mesma realidade de outras distros fora desse mundo. Os problemas que o Ubuntu tem, muitas vezes foram ocasionados pelo próprio Ubuntu, como ter diferentes versões.
E é fato, que muitos, só usam o snap porque é o caminho mais fácil, não porque exatamente funciona, tanto que, a quantidade de reclamação em relação a fechamentos repentinos, uso de disco, criação de loops atrapalhando a manutenção do sistema de particionamento, quebra de temas, atualização forçada em background, instalação forçada do snap por parte de alguma dependência, problema com cores datados, problemas de desempenho, como demora pra abrir, responder, fechar, acessar área do sistema...
Quando isso ocorre, é muito comum o usuário procurar alternativa, como o Flatpak, AppImage ou até mesmo um PPA (dentro do mundo Ubuntu), o repo ou tarball.


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

Andre (pinduvoz)
pinduvoz

(usa Debian)

Enviado em 27/01/2021 - 19:56h


O empacotamento universal de software para Linux foi considerado uma necessidade, mas sua aplicação veio "avacalhada" já no início. Em vez de termos um único tipo de pacote com os quais as principais distros concordassem (e usassem), temos snaps, flatpacks e appimages (três tipos diferentes, portanto, sem falar que pode haver outro que eu ainda não conheço).

Por conta disso, ou seja, pelo fato de não mudar nada, fico com meus debs e rpms.


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

Bilufe
bilufe

(usa KDE Neon)

Enviado em 27/01/2021 - 21:42h

Sanyo escreveu:

bilufe escreveu:

Sanyo escreveu:

Oxe, já vi fanboy de Windows, de Ubuntu, de Arch, mas é a primeira vez que vejo um de snap. O cara só fala disso. Parece aqueles adolescentes que descobrem uma banda nova, e querem que todos saibam da sua descoberta.
Acho que se a Canonical largar o desenvolvimento do snap, esse cara tira a própria vida.


Cara, eu sei reconhecer os problemas dos Snaps, mas falo tanto porque há informações que não são verdadeiras. Também uso Flatpak, uso Appimage, Nix Packages e o que tiver.

Sou a favor de inovar. Se os Snaps deixarem de existir vai por algo melhor.

Não parece... Err, inovar, mesmo que a força?


Ninguém te obriga a usar Ubuntu. Que força é essa que te obriga a usar Ubuntu e a usar Snaps?


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

Bilufe
bilufe

(usa KDE Neon)

Enviado em 27/01/2021 - 21:50h

pinduvoz escreveu:


O empacotamento universal de software para Linux foi considerado uma necessidade, mas sua aplicação veio "avacalhada" já no início. Em vez de termos um único tipo de pacote com os quais as principais distros concordassem (e usassem), temos snaps, flatpacks e appimages (três tipos diferentes, portanto, sem falar que pode haver outro que eu ainda não conheço).

Por conta disso, ou seja, pelo fato de não mudar nada, fico com meus debs e rpms.


Não existe uma unidade no mundo Linux, é óbvio que uma iniciativa nesse sentido teria diversos fornecedores.
Tem também o Nixpkg, mas os pacotes são construídos pelos robôs da distribuição NixOS. Eu tenho o Nixpkg configurado no meu KDE Neon, porém não tenho nenhum aplicativo instalado. O único programa que tentei rodar foi o Amarok, o qual não está disponível no KDE Neon, mas deu erro ao tentar rodar. Mas sim, já testei e quase tudo que instalei nos testes funcionou (Firefox, FeatherPad, Micropolis). A grande falha do Nixpkg é não ter um gerenciador de pacotes com interface gráfica, não possui integração com nenhuma loja de aplicativos.

Tem também o Orb, mas é meio que um concorrente do Appimage, quase não há softwares empacotados com o Orb.

Tem também o 0Install, esse me parece ser bem mais antigo que o Appimage, só que esse sistema não se popularizou no Linux e agora foca na distribuição de software para Windows. Também há poucos programas empacotados com ele, mas mais que o Orb.

Snap e Flatpak possuem um sistema de permissões tal qual há no Android, tornando o uso mais seguro que usar aplicações tradicionais. Aplicativos Snaps e Flatpak rodando em uma sandbox não enxergam o que outro aplicativo faz, nem possuem acesso direto ao sistema de arquivos (quem acessa o sistema de arquivos é uma ferramenta intermediária). Só essa evolução deveria ser considerada como uma melhoria importante na segurança do sistema.

Mas repito novamente, a grande vantagem do Snap e Flatpak é solucionar o problema da distribuição de softwares pelos desenvolvedores. Imagine um desenvolvedor que escreve softwares para o Ubuntu, existem ao menos quatro versões do Ubuntu em atividade: a versão 18.04, a versão 20.04, a versão 20.10 e a versão de desenvolvimento (21.04), imagine tendo que testar e adaptar o software para cada versão específica do Ubuntu, e ainda mais suportar outras distribuições como Fedora, Mandriva, Debian, etc. É um trabalho imenso. Mas Snap e Flatpak consertam isso. Um único pacote atende a todas as versões do Ubuntu e mais de 20 outras distribuições.




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

Mauricio Ferrari
mauricio123

(usa Slackware)

Enviado em 28/01/2021 - 21:10h


bilufe escreveu:

pinduvoz escreveu:


O empacotamento universal de software para Linux foi considerado uma necessidade, mas sua aplicação veio "avacalhada" já no início. Em vez de termos um único tipo de pacote com os quais as principais distros concordassem (e usassem), temos snaps, flatpacks e appimages (três tipos diferentes, portanto, sem falar que pode haver outro que eu ainda não conheço).

Por conta disso, ou seja, pelo fato de não mudar nada, fico com meus debs e rpms.


Não existe uma unidade no mundo Linux, é óbvio que uma iniciativa nesse sentido teria diversos fornecedores.
Tem também o Nixpkg, mas os pacotes são construídos pelos robôs da distribuição NixOS. Eu tenho o Nixpkg configurado no meu KDE Neon, porém não tenho nenhum aplicativo instalado. O único programa que tentei rodar foi o Amarok, o qual não está disponível no KDE Neon, mas deu erro ao tentar rodar. Mas sim, já testei e quase tudo que instalei nos testes funcionou (Firefox, FeatherPad, Micropolis). A grande falha do Nixpkg é não ter um gerenciador de pacotes com interface gráfica, não possui integração com nenhuma loja de aplicativos.

Tem também o Orb, mas é meio que um concorrente do Appimage, quase não há softwares empacotados com o Orb.

Tem também o 0Install, esse me parece ser bem mais antigo que o Appimage, só que esse sistema não se popularizou no Linux e agora foca na distribuição de software para Windows. Também há poucos programas empacotados com ele, mas mais que o Orb.

Snap e Flatpak possuem um sistema de permissões tal qual há no Android, tornando o uso mais seguro que usar aplicações tradicionais. Aplicativos Snaps e Flatpak rodando em uma sandbox não enxergam o que outro aplicativo faz, nem possuem acesso direto ao sistema de arquivos (quem acessa o sistema de arquivos é uma ferramenta intermediária). Só essa evolução deveria ser considerada como uma melhoria importante na segurança do sistema.

Mas repito novamente, a grande vantagem do Snap e Flatpak é solucionar o problema da distribuição de softwares pelos desenvolvedores. Imagine um desenvolvedor que escreve softwares para o Ubuntu, existem ao menos quatro versões do Ubuntu em atividade: a versão 18.04, a versão 20.04, a versão 20.10 e a versão de desenvolvimento (21.04), imagine tendo que testar e adaptar o software para cada versão específica do Ubuntu, e ainda mais suportar outras distribuições como Fedora, Mandriva, Debian, etc. É um trabalho imenso. Mas Snap e Flatpak consertam isso. Um único pacote atende a todas as versões do Ubuntu e mais de 20 outras distribuições.



É um bom argumento, contanto que o source desses pacotes estejam no github, pra mim esses desenvolvedores podem mandar bala.

___________________________________________________________
Conhecimento não se Leva para o Túmulo.
https://github.com/MauricioFerrari-NovaTrento



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

josinaldo
-josinaldo-

(usa Fedora)

Enviado em 29/01/2021 - 11:45h

E o lance das atualizações automáticas dos snaps?
tem como desativar? Se não tem, eu considero um PUPs, “Programa Potencialmente Indesejado".
é um app em execução sera que vai atualizar automaticamente?

* No Windows e macOS tem como desativar atualizações automáticas, bem como qualquer software de terceiros para o esses S.Os








Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts