Snap instalado por padrão no Linux Mint?


No último relatório do projeto linux mint, o fundador Clément Lefèbvre, tocou em um assunto polêmico para o sistema: a adoção de pacotes snaps. Onde reafirmou sua posição feita em 2019 em favor de não utilizá-los, e informou que na instalação padrão de softwares no Linux Mint 20, o APT irá bloquear a instalação do “snapd” (software que instala o suporte aos Snaps).

Um representante da Canonical, empresa que controla o Ubuntu respondeu ao comentário de Clément Lefèbvre quanto aos snaps:

"Snaps projetados pela Canonical com base em vários princípios que incluem segurança, facilidade de uso e redução da fragmentação no ecossistema Linux. Fora do Ubuntu, o Linux Mint tem o maior número de usuários em todas as distribuições compatíveis. Esses usuários optaram por instalar o Snaps com base nos motivos descritos acima, entre outros. Agradecemos e incentivamos a adoção dos Snaps disponíveis na Snapcraft Store . Gostaríamos que o Linux Mint se envolvesse conosco e com a nossa comunidade para discutir esses tópicos, como fazemos com outras distribuições, e trabalhar juntos daqui para frente "

No centro de toda confusão, Clément, cita o navegador Chromium, que desde o Ubuntu 19.10 é instalado via snap, mesmo quando instalado via APT. Alan Pope, gerente da comunidade Canonical para serviços de engenharia, disse que a empresa sempre soube que transferir a instalação para snap não era uma decisão trivial, mas achava que tinha boas razões, uma delas seria uma maior compatibilidade com versões antigas do sistema, já que o projeto usa recursos que podem não estar disponíveis em versões antigas.

Alan Pope, ainda disse que manter pacotes é um trabalho árduo, já que o aplicativo deve ser personalizado para funcionar nas mais diversas distribuições e suas versões, e as bibliotecas específicas. Essa é uma das razões pela qual várias empresas não portam seus aplicativos para linux, segundo Frank Karlitschek, fundador do NextCloud e ex-membro do conselho KDE, e vários desenvolvedores na LAS(Linux Application Summit) concordaram com ele. Eles veem o futuro do Desktop em apps de contêiner.

O próprio Linus Torvalds, prefere essa abordagem, já que no ano passado desejou “sermos melhores em ter um desktop padronizado que atravesse as distribuições". Ele também está irritado com a forma como a “fragmentação dos diferentes fornecedores reteve a área de trabalho”.

Se tudo ocorrer bem, veremos o Mint e o Ubuntu chegar em um acordo, o que nos deixará bem felizes. Qual sua opinião sobre o assunto? Deixe nos comentários, e até a próxima notícia!

Fonte: ZDNet

3 curtidas

Já tem alguns tópicos sobre o mesmo tema, e eu acho que tem muita polêmica a toa. Todas as matérias que eu vejo dão a impressão de que o Mint irá proibir completamente o uso do Snap, quando na verdade só irá proibir a instalação automática do mesmo, algo que acontece ao executar o comando sudo apt install chromium-browser nos Ubuntu mais recentes. Quem gosta, usa e instala Snaps continuará utilizando-os normalmente.

3 curtidas

O que eu sei é que só o snapd aqui estava consumindo quase 400MB de RAM à toa, visto que o único app em Snap que eu utilizava era o Whatsdesk…

Depois que resolvi usar ele no modo “Google App”, os Snaps e a SnapStore se tornaram pra mim algo inútil… então dei um “sudo apt remove --purge snapd gnome-software-plugin-snap” e o desempenho e responsividade do sistema melhoraram como mágica…

Tanto a abertura da Gnome-Software como as buscas dentro dela ficaram muito mais rápidas… enfim… “O que não faz bem pro meu sistema, não me faz falta” rs

4 curtidas

Dá ojeriza, essa conversa escorregadia da Canonical, convidando o Mint para “se envolver” com Snap e “discutir”. ─ Discutir decisões empresariais da Canonical é perda de tempo. Quando decidem, está decidido, e se limitam a repetir argumentos, muitas vezes capciosos.

Dizer que “Esses usuários optaram por instalar o Snaps”, como se o Mint malvadão estivesse deixando de atender seus usuários.

Essa conversa mole para justificar a instalação sorrateira de um chromium.snap quando se pede .deb ─ alegando que “uma das razões pela qual várias empresas não portam seus aplicativos para linux”. ─ Ora, Chromium é um aplicativo Linux.

Dizer que dá trabalho manter Chromium para várias versões simultâneas do Ubuntu ─ quando, na verdade, o que dá trabalho é manter dezenas de milhares de pacotes, ou seja, manter várias versões do ubuntu, cada uma com todas as dezenas de milhares de pacotes.

2 curtidas

O problema é exatamente o snap ou um você pedir um pacote .deb e receber outro no apt? Por que dentro do APT isso acontece também, você pede para instalar um pacote e recebe outro (ex.: Debian, o pacote mysql-server instala o mariadb). Nesse caso, podemos aplicar o mesmo argumento (pedi o mysql e recebi o mariadb), mas não vemos quase ninguém reclamando disso.

Pode até parecer igual, mas é muito diferente. O sistema APT é pensado para instalar pacotes .Deb e automaticamente instalar as dependências também via pacotes .Deb. Ou seja, usando o seu exemplo, ao instalar o pacote “mysql-server”, o APT também irá instalar o pacote “mariadb”, ambos via pacotes .deb, e isso é perfeitamente normal e esperado. No fim, é garantido que todos os pacotes instalados em uma execução do APT serão .deb.

Já no caso do pacote do Chromium, o APT instala o pacote .deb do Snap, o qual instala o Chromium em Snap. Ou seja, a garantia de que o APT só instala .deb não é mais válida, e isso abre um precedente bem complicado. O APT até permite a execução automática scripts antes e depois da instalação de cada pacote por definição, porém esses scripts foram originalmente pensados para permitir a verificação ou a configuração de coisas no sistema, e não para instalar outras coisas, que é justamente como a instalação do pacote Snap acontece.

Como eu já falei nos outros posts, eu não tenho contra os Snaps. O problema é a inconsistência que isso traz para o sistema. Um mesmo comando pode ter resultados completamente diferentes dependendo dos repositórios utilizados, por exemplo, pois um pode conter a versão completa do pacote e outro pode ter apenas um link para um Snap, já imaginando isso acontecendo com mais pacotes. Além das outras inconsistência que já comentei nos outros posts.

2 curtidas

Na minha humilde opinião, se o Mint discorda de como a Canonical rege o assunto eles deveriam passar a utilizar de vez o Debian como base. Na minha opinião é meio contraditório você barrar uma forma de instalação por acreditar que os snaps são ruins mas continuar usando como base o sistema que prega o uso de snaps. E de certa forma, o cara da Canonical está certo. Manter pacotes e a compatibilidade deles com todas as versões legadas que ainda estão sendo mantidas é um grande custo em desenvolvedores por hora. Não sou bitch da Canonical, apenas entendendo o lado dela como empresa. Que o mint passe o LMDE como default e esqueça o Ubuntu.

3 curtidas

O Ubuntu é um projeto de código-aberto, e portanto pode ser utilizado por qualquer um. A base do Ubuntu é boa, algumas decisões que eles tomam nem tanto. Se fossem, não haveriam outros muitos projetos baseados no Ubuntu, cada um com suas próprias escolhas. Simples assim.


Edit:
E mesmo assim, não é a toa que o Mint mantém o LMDE.

3 curtidas

Meu ponto é que existem pessoas argumentando que as pessoas seriam enganadas ou não estariam sendo contempladas por que o formato de empacotamento mudou, sendo que isso já acontece no apt.

Seu argumento é um pouco diferente, no meu entendimento vai em linha de que é errado um formato de empacotamento entregar um pacote em outro formato. Nesse sentido, se um dev usasse o apt para distribuir um binário em appimage ou flatpak, deveríamos reclamar da mesma forma.

Sobre a questão da inconsistência, isso pode acontecer no apt também. Ignorando a questão da licença, uma distro poderia usar o pacote mysql-server para de fato instalar o MySQL, ao invés do Mariadb como faz o Debian. Ou seja, dentro do APT, isso já é possível e provavelmente acontece em outros casos.

1 curtida

Não, não acontece. Pelo menos não nos repositórios oficiais.

Sim. Exatamente.

Primeiro que o MariaDB é um fork aprimorado do MySQL. Segundo que o APT permite sugestões e recomendações de outros pacotes compatíveis, como é o MariaDB para o MySQL, e como acontece com várias outras bibliotecas. Por exemplo, analise a saída do comando apt depends mysql-server-5.7. Novamente, isso é previsto, tanto que é explicitado nas opções do próprio APT, como mostra o comando que citei, mas aposto que não vai aparecer um snap install chromium-browser em alguma saída do APT.


Edit:
E o Debian usa o MariaDB justamente pela questão da licença que você citou, e isso será exposto pelo comando: apt depends mysql-server
Ou seja, você tem como saber exatamente o que está instalando.
Basta ver os detalhes dos pacotes:

E mais, ao executar apt install mysql-server o APT irá exibir todos os pacotes que serão instalados e dependerá da pessoa aceitar ou não aquilo. Vai ser especificado que o MariaDB será instalado, e a pessoa pode simplesmente não aceitar e cancelar a instalação. Isso não acontece no Chromium.


Por fim, olhe os detalhes do pacote do Chromium:

Diz apenas que depende do snapd, mas além da descrição do pacote que diz " Transitional package - chromium-browser → chromium snap", não tem nada no pacote que diz que o chromium será instalado via Snap.

5 curtidas

Minha opinião, snaps, flatpak, appimage estão ai para ficar quer vc queira ou não pode rolar espernear, eles devem receber melhorias e otimizações com o tempo cabe a nós termos paciência também ao invés de ficar criando discussões infinita, deb, rpm deve ficar por ai por anos (ou talvez nunca acabam ) e estão ai para serem usados se preferir. Essa será a ultima vez que pretendo comentar a respeito, sem mas.

Concordo com o ponto de vista da Canonical.

“No centro de toda confusão, Clément, cita o navegador Chromium, que desde o Ubuntu 19.10 é instalado via snap, mesmo quando instalado via APT.”
Pelo menos comigo isso nunca aconteceu.

1 curtida

Não, não acontece. Pelo menos não nos repositórios oficiais.

Acontece, quando eu peço para instalar o mysql-server eu espero que o mysql seja instalado, não o mariadb. Da mesma forma que quando eu peço para instalar o Chromium pelo apt eu espero um .deb e não um snap.

O argumento DB ser fork compatível do outro pode ser aplicado ao Chromium também, dado que o Chromium snap ou .deb também são compatíveis pois são a mesma aplicação.

Sobre o apt ser mais informativo no caso do mysql do que o chromium, caso o apt mostrasse certinho o que está acontecendo, você estaria ok com isso? Por que se não, o argumento não vale para todos os casos.

Por fim, existem alguns pacotes do python que são distribuídos via APT, se algum deles rodar o PIP (gestor de pacotes python) para finalizar o seu setup e instalar alguma dependência que não esteja no APT, vale reclamar da mesma forma?

E se um pacote APT usar o Wget para baixar outro pacote da internet (como aqueles instaladores do Oracle JDK), não é o APT instalando pacotes de uma fonte externa ao APT, como é com os snaps?

Por que não reclamamos desses também?

2 curtidas

Novamente, não acontece. Não existe, nos repositórios oficiais, nenhum pacote que seja instalado via wget/curl. O PIP é apenas um facilitador, mas os módulos Python podem ser vistos como um pacote .deb como qualquer outro, assim como um pacote de fontes, de tema, de wallpaper, e qualquer outra coisa no sistema. Um pacote .deb não necessariamente precisa instalar um programa.

E mesmo quando você instala o pacote python-pip, apenas o PIP é instalado e não um monte de pacotes Python. Até mesmo os outros pacotes Python são separados em pacotes .deb, e quando você instala um, você só estará instalando esse um e as dependências, que serão especificadas pelo APT. Se o PIP fosse chamado para executar alguma instalação via APT ai teríamos um problema, mas isso não acontece.

Se você realmente quisesse instalar uma versão específica você deveria instalar o pacote “mysql-server-5.7”, por exemplo, pois o “mysql-server” é apenas um pacote transicional que pode ser configurado para instalar tanto o MariaDB quanto o MySQL, ambos em .deb e ambos são Servidores MySQL. Mesma coisa acontece com vários pacotes, como o “default-jdk”.

Não. Os Snaps usam uma infraestrutura bem diferente para serem executados, não usam as configurações e bibliotecas padrão do sistema, não são instalados nos mesmos diretórios que os outros pacotes, e são baixados de uma fonte diferente usada pelo APT.

A questão não é de ser mais informativo ou não. A questão é que é IMPOSSÍVEL descrever uma dependência em Snap dentro do .deb. No máximo vai ter a dependência do snapd, mas não tem como colocar o chromium-snap como dependência simplesmente porque não existe tal pacote .deb.

Muito provavelmente já aconteceu, e você nem sabe disso. Na época eu mesmo fiz o teste:


E na boa, galera, simplesmente continuem no Ubuntu, que eu continuarei no Mint.

4 curtidas

Acontece. No meu caso, após eu ter removido o Snapd, ele se instalou sozinho após uma atualização e tem até mesmo um vídeo bem irônico onde isso ocorre. Nesse vídeo do canal DistroTube, Derek (dono do canal) mostra que você não é obrigado usar Snaps caso você não queira e para provar isso, ele tenta remover o Snapd e instalar Flatpaks, porém durante esse processo, no minuto 5:54 mais especificamente, o Snapd é instalado como uma dependência sem ele perceber, tanto que isso virou uma piada nos comentários do vídeo.

4 curtidas

hahahaahahah. Não tinha visto esse vídeo ainda. E isso porque o Snapd foi instalado junto com o plugin do Flatpak para o gnome-sofware. Provavelmente se ele tivesse usado o --no-install-recommends isso não aconteceria, mas ainda assim mostra bem o problema.


E só mais um detalhe, para deixar bem claro a diferença entre usar o PIP, o APT e o Snap:

Ao instalar um módulo Python usando o APT, os arquivos são instalados no diretório /usr/lib/python3/dist-packages, enquanto que instalando via PIP os arquivos são instalados em ~/.local/lib/python3.8/site-packages. Isso faz com que os módulos instalados via APT não possam ser modificados pelo PIP, mesmo se executado como sudo, o que garante que o sistema não quebre. Por exemplo, uma atualização do módulo pode trazer uma versão incompatível com os scripts do sistema. Já os Snaps são instalados em /snaps.

Exemplos:

  • PyYAML, instalado via APT:

      $ pip3 show PyYAML
      Name: PyYAML
      Version: 5.3.1
      Summary: YAML parser and emitter for Python
      Home-page: https://github.com/yaml/pyyaml
      Author: Kirill Simonov
      Author-email: xi@resolvent.net
      License: MIT
      Location: /usr/lib/python3/dist-packages
      Requires: 
      Required-by:
    
      $ pip3 uninstall PyYAML
      Found existing installation: PyYAML 5.3.1
      Not uninstalling pyyaml at /usr/lib/python3/dist-packages, outside environment /usr
      Can't uninstall 'PyYAML'. No files were found to uninstall.
    
      $ sudo pip3 uninstall PyYAML
      Found existing installation: PyYAML 5.3.1
      Not uninstalling pyyaml at /usr/lib/python3/dist-packages, outside environment /usr
      Can't uninstall 'PyYAML'. No files were found to uninstall.
    
  • scikit-learn, instalado via PIP3:

      $ pip3 show scikit-learn
      Name: scikit-learn
      Version: 0.22.2.post1
      Summary: A set of python modules for machine learning and data mining
      Home-page: http://scikit-learn.org
      Author: None
      Author-email: None
      License: new BSD
      Location: /home/bruno/.local/lib/python3.8/site-packages
      Requires: scipy, joblib, numpy
      Required-by: sklearn
    

Além disso, quando o pacote é instalado via APT, é possível listar todos os arquivos instalados, com a ajuda do comando dpkg.
Exemplo:

$ dpkg --listfiles python3-yaml 
/.
/usr
/usr/lib
/usr/lib/python3
/usr/lib/python3/dist-packages
/usr/lib/python3/dist-packages/PyYAML-5.3.1.egg-info
/usr/lib/python3/dist-packages/_yaml.cpython-38-x86_64-linux-gnu.so
/usr/lib/python3/dist-packages/yaml
/usr/lib/python3/dist-packages/yaml/__init__.py
/usr/lib/python3/dist-packages/yaml/composer.py
/usr/lib/python3/dist-packages/yaml/constructor.py
/usr/lib/python3/dist-packages/yaml/cyaml.py
/usr/lib/python3/dist-packages/yaml/dumper.py
/usr/lib/python3/dist-packages/yaml/emitter.py
/usr/lib/python3/dist-packages/yaml/error.py
/usr/lib/python3/dist-packages/yaml/events.py
/usr/lib/python3/dist-packages/yaml/loader.py
/usr/lib/python3/dist-packages/yaml/nodes.py
/usr/lib/python3/dist-packages/yaml/parser.py
/usr/lib/python3/dist-packages/yaml/reader.py
/usr/lib/python3/dist-packages/yaml/representer.py
/usr/lib/python3/dist-packages/yaml/resolver.py
/usr/lib/python3/dist-packages/yaml/scanner.py
/usr/lib/python3/dist-packages/yaml/serializer.py
/usr/lib/python3/dist-packages/yaml/tokens.py
/usr/share
/usr/share/doc
/usr/share/doc/python3-yaml
/usr/share/doc/python3-yaml/README
/usr/share/doc/python3-yaml/changelog.Debian.gz
/usr/share/doc/python3-yaml/copyright

Porém, ao instalar o pacote chromium-browser , via APT, o resultado do mesmo comando é o seguinte. Note que existe apenas os atalhos, a documentação e os ícones.

$ dpkg --listfiles chromium-browser 
/.
/usr
/usr/bin
/usr/bin/chromium-browser
/usr/share
/usr/share/applications
/usr/share/applications/chromium-browser.desktop
/usr/share/apport
/usr/share/apport/package-hooks
/usr/share/apport/package-hooks/chromium-browser.py
/usr/share/doc
/usr/share/doc/chromium-browser
/usr/share/doc/chromium-browser/changelog.Debian.gz
/usr/share/doc/chromium-browser/copyright
/usr/share/icons
/usr/share/icons/hicolor
/usr/share/icons/hicolor/128x128
/usr/share/icons/hicolor/128x128/apps
/usr/share/icons/hicolor/128x128/apps/chromium-browser.png
/usr/share/icons/hicolor/22x22
/usr/share/icons/hicolor/22x22/apps
/usr/share/icons/hicolor/22x22/apps/chromium-browser.png
/usr/share/icons/hicolor/24x24
/usr/share/icons/hicolor/24x24/apps
/usr/share/icons/hicolor/24x24/apps/chromium-browser.png
/usr/share/icons/hicolor/256x256
/usr/share/icons/hicolor/256x256/apps
/usr/share/icons/hicolor/256x256/apps/chromium-browser.png
/usr/share/icons/hicolor/48x48
/usr/share/icons/hicolor/48x48/apps
/usr/share/icons/hicolor/48x48/apps/chromium-browser.png
/usr/share/icons/hicolor/64x64
/usr/share/icons/hicolor/64x64/apps
/usr/share/icons/hicolor/64x64/apps/chromium-browser.png
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/chromium-browser
/usr/share/pixmaps
/usr/share/pixmaps/chromium-browser.png
3 curtidas

Não, o problema (do meu ponto de vista) é totalmente outro.

Primeiro, não tenho nada contra a “categoria” (sandbox?) Flatpak, AppImage, Snap ─ compreendo que são iniciativas importantes ─ mas isto não significa que eu concorde em ser “obrigado” a usar nenhum deles, para ter alguma coisa tão básica quanto o Chromium.

(Nesta discussão específica, sim, considero Snap a pior das 3. Mas isso não é o ponto principal. Pode ser que melhore, assim espero, e eu mude de opinião. Acho que ainda não é o caso).

E o segundo ponto, é que tenho ojeriza a “conversa de vendedor”, coaching, aquele papo de “nossa missão” etc. ─ Isso foi o que de fato me deu engulhos, na resposta da Canonical ao Mint: ─ Uma mistura de cinismo, desfaçatez, enganação, que a Canonical sabe que não fará nenhum efeito no Clément. Não são argumentos. É uma “jogada política” para a plateia. Para isolar o Clément, o Mint, tentar deixá-lo “mal” com uma parte de seus seguidores, que estejam meio distraídos.

É isso. E se não fosse isso, eu nem teria dito nada. Apenas, leria os argumentos que aparecessem por aqui, e marcaria para acompanhar a conversa, pois já faz 1 ano ou 2, que procuro ler tudo sobre o assunto, e vou favoritando tudo que acrescente informações, para encontrar de novo o que achei relevante. ─ Nesse debate, ainda me interessa mais ler, do que dar pitaco.

Na parte técnica, principalmente, leio, mas não opino. Há muito tempo, resolvi ser mero “usuário”. Mas computador de mesa (desktop), para mim, é ferramenta de trabalho. Coisa muito séria, portanto. E foi por ser assunto sério, que há muitos anos resolvi trocar o Windows pelo Linux.

O significado do Linux, para mim, é o de “comunidade”. O usuário, em 90% dos casos, não vai parar para investigar o código-fonte. Mas sabe que milhares de pessoas estão sempre de olho. Quem não pode fazer isso, pode contribuir de várias outras formas ─ fazendo doações, dando retorno de algum problema para ajudar a solucionar, ou ajudando os iniciantes, divulgando etc.

Quando surgiram empresas “apoiando” ─ e usufruindo ─ parecia uma coisa ótima. Não critico, pois era um passo necessário.

Depois, uma empresa distorceu numa direção, outra distorceu em outra direção. Tudo bem, acontece. São coisas da vida. E sempre há uma parte da comunidade que permanece independente, outra parte, “relativamente independente”. O Mint talvez esteja neste último caso. Por isso mesmo, mantém o LMDE. Não concordo que deva abaixar a cabeça e dizer “sim senhor” pra Canonical ─ que usufrui do esforço de uma comunidade enorme, o Debian, e não age assim. Por que o Mint deveria? Gosto da atitude do Mint, e só não instalei (ainda) no novo PC, porque eu tinha de estabelecer minhas prioridades. Venceu o KDE Neon, para instalar primeiro. (Sim, faço dualboot de várias distros).

Kurumin foi minha primeira distro, e quando faltou, Kubuntu se tornou minha tábua de salvação, como iniciante. Usei de 2009 até o ano passado. No começo, fazia dualboot com Mint numa época, e com o Debian em outras épocas. Felizmente, desde 2017 passei a experimentar Manjaro, openSUSE e várias outras, pois sentia necessidade de não “depender” da Canonical. Ano passado, Kubuntu já tinha virado “opcional”. Eu tinha trocado o LTS pelo “experimental”, ou seja, instalar no início do desenvolvimento de uma nova versão, e usar até ser lançada. Aí, passava para o início do desenvolvimento da versão seguinte. Como se fosse uma rolling-distro. Por isso, peguei o tal chromium.snap antes de quase todo mundo.

Eu tinha removido o Snap ─ assim como sempre removo PackageKit, Plasma-Discover, Unattended-upgrades etc. ─ Uso apt update para “ver” o que vem pela frente, depois uso o Synaptic para “aplicar”, bem como para pesquisar e instalar alguma coisa nova. ─ E um belo dia, o Snap foi instalado de novo. Bastou eu me distrair 1 minuto. Investiguei, mais tarde, e descobri que voltou junto com uma “atualização” do Chromium.

O suposto “Chromium”, por sua vez, veio todo corongado. Não dava para salvar nenhum download, não obedecia à configuração do ambiente KDE… Avisei em vários foruns, e recebi mil dicas de como “me adaptar” ─ ou seja, aprender, trabalhar etc., para maior glória de uma decisão da Canonical. ─ Optei por deletar o Kubuntu “development”, e já faz +/- 1 ano que deixei de ter Kubuntu na minha máquina (após 10 anos).

Continuei usando openSUSE, Arch, Debian, Fedora, KDE Neon, Mint, PCLinuxOS, Mageia, Slackware, Sabayon, instalei o Void ─ e nenhum deles tentou me forçar a usar Snap ou Flatpak, até hoje. ─ Ok, desde Janeiro estou sem Mint, então não sei se ele teria tentado me obrigar a usar Flatpak. (Tenho essa curiosidade, mas não tenho pressa. Um dia vou instalar o Mint de novo, e vou ficar sabendo… a menos que algum de vocês possa me adiantar essa informação, o que eu agradeceria muito: - O que acontece quando um usuário do Mint tenta instalar o Chromium?).

Vejam ─ é um respeitável leque de distros ─ várias tocadas pelas maiores empresas Linux, e várias tocadas pelas maiores comunidades Linux. Só posso levantar as mãos para os céus e agradecer a boa hora em que resolvi investir nesse “dualboot” das distros mais relevantes, representativas dos principais “troncos” do Linux, umas com SystemD, outras sem. Para mim, isto significa “independência”. Gosto do Fedora, gosto do openSUSE, mas não “dependo” dessas empresas. Pra mim, isso é o paraíso ─ desde que não passo de mero “usuário”, incapaz de montar meu próprio LFS. (Ok, ainda vou tentar o Gentoo, antes).

Dentro desse leque de liberdades, as decisões da Red Hat ou da SuSE não me prejudicam muito. ─ Ficou claro, para mim, o caráter “personalista” do dono da Canonical. Quando jovem, deu a louca de torrar dinheiro para mandar CDs para o mundo inteiro, di grátis. Ótimo! De lá para cá, usou e abusou de todo tipo de guinadas bruscas. Agora, concluiu que “negócios são negócios”. De repente, manter várias versões de um pacote básico, como o Chromium, virou um sacrifício inominável ─ embora mantenha várias versões de 60.000+ pacotes, não é mesmo? Para mim, isso foi “pensado”. O pacote Chromium foi escolhido a dedo. E não foi com as melhores intenções do mundo. E não foi com nenhum dos propósitos declarados. Não tem nada a ver com os 1.001 pretextos que ele já alegou, nos últimos 12 meses. Foi uma jogada. E se eu gostasse de ser manipulado desse jeito, podia ter ficado no Windows ─ pois, com todos os defeitos que a M$ tem, jamais “variou” tanto quanto o dono da Canonical, que mais parece biruta de aeroporto, que vira em todas as direções, ao menor sopro de vento.

Se alguém aqui gostar de “teorias da conspiração”, eu poderia sugerir 1.001 ideias ─ a começar pelas doações e subsequente entrada de representantes da M$ e outras mega-corporações no conselho da comunidade Debian etc. ─ mas isso é outra das muitas “realidades da vida”, que a gente pode até xingar, mas não há muito que se possa fazer, se formos realistas.

Não tenho nada contra Flatpak, AppImage, Snap ─ embora veja diferenças “políticas” (mais do que técnicas) entre elas. ─ No caso do Snap, é o que me desagrada mais, pois pode-se supor que eventuais falhas técnicas são passíveis de superação. E os interesses envolvidos, bem que podem fazer com que milhares de desenvolvedores dêem essa melhoria de presente à Canonical. Só na “política” da Canonical, é que a comunidade não tem como influir. Nesse aspecto, qualquer discussão é +/- perda de tempo.

Meu desagrado é mais genérico ─ e ninguém é obrigado a concordar comigo. ─ Acho que, por um lado, esses formatos (sandbox? desculpem, não lembro agora o nome dessa categoria) são um desenvolvimento necessário e inevitável. Por outro lado, tenho medo do “individualismo”, que a sociedade capitalista, competitiva etc. joga neles. Uma quebra de solidariedade. O contrário do sentido da “comunidade”.

Por “tradição”, os desenvolvedores contribuíam para algo comum, integrado a um conjunto de bibliotecas ─ e os mantenedores das distros zelavam pela consistência no conjunto. ─ É claro que isso sacrificava as equipes das distros. E também é claro que muitos desenvolvedores, como indivíduos, sonhavam com “liberdade”… para ganharem mais, individualmente. Quem pode condená-los, numa sociedade competitiva, cada vez mais dura, por desejarem o melhor para si mesmos e para suas famílias? Difícil criticar.

Gostaria de estar enganado, mas receio que o desenvolvimento (inevitável) desses empacotamentos autônomos atraia cada vez mais desenvolvedores ─ às custas das equipes de mantenedores das distros, que vão acabar ficando com o ônus, mas sem os bônus correspondentes.

Esse possível “perigo” ─ e quero estar errado ─ é muito mais insidioso do que as grandes corporações de Linux, ou a entrada de grandes corporações (externas) em conselhos de comunidades como a do Debian. É insidioso porque age sobre cada um dos milhares de desenvolvedores, levando-os do esforço comunitário para a (desculpável) busca do lucro pessoal.

Viajei na maionese, né.

Mas é na maionese que reside o busílis.

2 curtidas

Na verdade, o snapd não é dependência é um pacote recomedado, veja esse log:

natanael@honeycomb:~$ sudo apt install gnome-software-plugin-flatpak --no-install-recommends 
Lendo listas de pacotes... Pronto
Construindo árvore de dependências       
Lendo informação de estado... Pronto
The following additional packages will be installed:
  flatpak gir1.2-goa-1.0 gir1.2-snapd-1 gnome-software
  gnome-software-common libappstream-glib8
  libcairo-gobject-perl libcairo-perl
  libextutils-depends-perl libextutils-pkgconfig-perl
  libflatpak0 libglib-object-introspection-perl libglib-perl
  libgspell-1-2 libgspell-1-common libgtk3-perl libostree-1-1
  pkg-config python3-dateutil software-properties-gtk
Pacotes sugeridos:
  libfont-freetype-perl
Pacotes recomendados:
  xdg-desktop-portal xdg-desktop-portal-gtk
  | xdg-desktop-portal-backend gnome-software-plugin-snap
  gnome-session-bin | xfce4-session | mate-session-manager
Os NOVOS pacotes a seguir serão instalados:
  flatpak gir1.2-goa-1.0 gir1.2-snapd-1 gnome-software
  gnome-software-common gnome-software-plugin-flatpak
  libappstream-glib8 libcairo-gobject-perl libcairo-perl
  libextutils-depends-perl libextutils-pkgconfig-perl
  libflatpak0 libglib-object-introspection-perl libglib-perl
  libgspell-1-2 libgspell-1-common libgtk3-perl libostree-1-1
  pkg-config python3-dateutil software-properties-gtk
0 pacotes atualizados, 21 pacotes novos instalados, 0 a serem removidos e 19 não atualizados.
É preciso baixar 9.112 kB de arquivos.
Depois desta operação, 24,3 MB adicionais de espaço em disco serão usados.
Você quer continuar? [S/n] 

Ele só instalou o plugin da forma errada, o .deb tem:

  • os pacotes que ele depende
  • os pacotes recomendados pelo desenvolvedor
  • os pacotes sugeridos pelo mantenedor do repositório

Como o APT gerencia o sistema, ele presume que o usuário quer os pacotes tal qual o desenvolvedor do sistema quer então, é necessário passar a flag --no-install-recommends

Não exatamente o APT pode ser usado pra manipular teoricamente qualquer tipo de pacote, e você sequer precisa instalar eles no /, o ALT Linux e o pkg2apimage fazem esse tipo de coisa

E iiso não é verdade, snaps são montados aí, eles são “instalados” em /var/lib/snap, eles são apenas imagens comprimidas (assim como o AppImage) e são baixados em diretórios especiais e montados, e não instalados, pelo menos não no modelo tradicional

1 curtida