removido
(usa Nenhuma)
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.