A poucas semanas atrás, a Canonical anunciou suporte de distribuição cruzada para o mecanismo de entrega de aplicativos Snap, um que poderia suportar aplicativos móveis, desktop e baseados em servidor. O anúncio desmanchou algumas penas dentro da comunidade Linux, que viu poucas evidências de qualquer outra distro Linux que suportasse Snaps.
Snap é a tentativa da Canonical de refinar o mecanismo de empacotamento e entrega de aplicativos na plataforma Linux. A origem do Snap encontra suas raízes no Click, uma solução que a Canonical criou para sua plataforma móvel em 2014, para lidar com a complexidade da entrega de aplicativos para usuários de telefones e tablets Ubuntu, um ecossistema muito diferente dos desktops e servidores. Além disso, a tecnologia móvel também precisava confinar os aplicativos e armazená-los no sandbox, para que não comprometessem toda a plataforma.
Click permitiu que os desenvolvedores reunissem todas as dependências em um único pacote de aplicativos, para que os usuários e desenvolvedores não precisassem se preocupar com sistemas e bibliotecas de aplicativos conflitantes. Isso permitiu que os desenvolvedores usassem as bibliotecas mais recentes em seus aplicativos, para oferecer novos recursos à medida que eram desacoplados das bibliotecas instaladas no sistema.
>
Beyond Mobile to Servers e IoT
Click evoluiu para Snap e a Canonical estendeu seu uso potencial para o servidor, nuvem, Internet das Coisas (IoT) e espaços de desktop. Com o lançamento do Ubuntu 16.04 em abril, a Canonical trouxe oficialmente o Snap para o desktop Ubuntu.
Canonical também está desenvolvendo o Snappy Ubuntu Core, um minúsculo sistema operacional baseado em Linux para implantações de contêineres em larga escala, dispositivos IoT e muito mais, e qualquer coisa que necessite de atualizações transitórias e de pequenas pegadas. O Snappy Ubuntu Core funciona mais ou menos como o sistema operacional Chrome do Google e o CoreOS, onde oferece atualizações transitórias baseadas em imagens para o sistema e aplicativos que podem ser revertidos. Simultaneamente, oferece o confinamento que é conhecido no mundo dos contentores.
Snap é a alma dessa tecnologia.
A Mensagem de Entrega de Aplicações Linux
O modelo de entrega de aplicações existente no Linux tem muitas falhas. O mundo Linux está dividido em dois campos de empacotamento de aplicativos: rpm e deb. Além disso, existem versões diferentes das mesmas distribuições que usam bibliotecas diferentes, então torna-se um desafio para desenvolvedores de aplicativos empacotar aplicativos para Linux.
Como resultado, desenvolvedores de aplicativos não podem tirar vantagem das bibliotecas mais recentes e oferecer mais recursos aos seus usuários se a distribuição ainda estiver usando bibliotecas antigas.
Na maioria dos casos, desenvolvedores de aplicativos de código aberto não empacotam seus aplicativos para distribuições. Aplicativos populares ou há muito estabelecidos geralmente são empacotados pelos desenvolvedores da distro. Novos ou menos populares são empacotados pelo upstream para cada distro que eles querem suportar, ou não são oferecidos como um pacote de distro em absoluto. Quando uma nova versão de um aplicativo é lançada, estes desenvolvedores testam o aplicativo e então o disponibilizam para a distro. Como você pode ver, ao invés do desenvolvedor do aplicativo escrever apenas um aplicativo para toda a plataforma, que neste caso é Linux, há muitas pessoas trazendo esse aplicativo para os usuários.
Adiciona mais complexidade.
Existem casos em que o Windows e o MacOS recebem as últimas versões imediatamente, já que os aplicativos são empacotados pelos desenvolvedores primários, enquanto as distribuições Linux podem demorar um pouco. Isso não é tudo; algumas distros as recebem rapidamente e outras têm que esperar semanas ou meses.
No caso de aplicativos comerciais como Skype, Dropbox, Chrome, o ônus está no desenvolvedor principal para empacotar aplicativos e oferecer binários para diferentes distribuições. Muitos aplicativos não funcionam em versões mais antigas, porém suportadas, de muitas distribuições.
Em uma palavra, é uma bagunça.
Even o criador do Linux, Linus Torvalds, não está satisfeito com o modelo de entrega de aplicativos existente no Linux. Ele não oferece binários de seus aplicativos para a plataforma Linux citando esta bagunça. Dirk Hohndel, o mantenedor do Subsurface (um projeto iniciado por Linus), explicou, “A situação atual com dezenas de distribuições, cada uma com regras diferentes, cada uma com versões diferentes de bibliotecas diferentes, algumas com certas bibliotecas faltando, cada uma com ferramentas de empacotamento e formatos de empacotamento diferentes … que basicamente diz aos desenvolvedores de aplicativos ‘vão embora, concentrem-se em plataformas que se preocupam com aplicativos’.
“O empacotamento de aplicações é extremamente importante, mas também a proveniência e manutenção de todas as peças envolvidas”, concordou Gunnar Hellekson, diretor de gerenciamento de produtos do Red Hat Enterprise Linux.
Snap foi projetado para trazer alguma ordem a este estado de coisas. Mas se ela será adotada é outra questão inteiramente.
Hellekson argumentou que ferramentas como Snap não “resolvem magicamente problemas de interoperabilidade entre distribuições Linux, e na verdade transferem mais responsabilidade pela manutenção e segurança para os fornecedores de aplicações. Desta forma, eles poderiam tornar o desenvolvimento no Linux ainda mais difícil, apesar dos muitos benefícios para os usuários”
“As vantagens do Snap estão diretamente relacionadas às suas desvantagens … em essência, o Snap é o equivalente à ligação estática – é conveniente por um lado, cria duplicação e desafios no que diz respeito à segurança (e patching de segurança) por outro lado”, disse Gerald Pfeifer, vice-presidente de produtos e programas de tecnologia da SUSE.
No entanto, nem todos são da mesma opinião. Brandon Philips, co-fundador e diretor de tecnologia da CoreOS, nos disse que os recipientes são o futuro dos aplicativos no Linux. Mas os contentores Docker não podem ser usados em todo o lado. Eles têm as suas limitações. O que nós precisamos é de uma solução tipo container, algo como Snap.
Durante outra entrevista, o desenvolvedor líder do kernel Linux Greg Kroah-Hartman nos disse que o Android tem feito containers “para seus aplicativos há oito ou nove anos”. Cada aplicativo roda em seu próprio namespace. Ele não pode ver fora disso. Essa é a maneira que você tem que fazer isso. Esse é o futuro do Linux e a forma como os sistemas funcionam”. Ele disse que o Snap é o mesmo conceito, a mesma idéia.
Snap Goes Cross Platform
O sucesso do Snap depende muito de sua adoção pela comunidade de código aberto maior. De que serve um formato de aplicativo se ninguém o está usando? Como uma tecnologia somente Ubuntu, que pode nem mesmo ser oficialmente suportada por seus derivados como Linux Mint, neon do KDE ou SO elementar, o Snap poderia enfrentar uma carreira de pouco sucesso.
Quando a Canonical anunciou o Snap, afirmou em uma conferência de imprensa que tem trabalhado com várias distribuições para adicionar suporte ao Snap.
Canonical disse que o Snaps está nativamente disponível para Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity, e Xubuntu. A Canonical também está trabalhando na validação de Snaps no CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt e Red Hat Enterprise Linux.
Canonical e SUSE não estão atualmente envolvidos no desenvolvimento em torno da colaboração em Snaps, e de fato, parece que isto não foi o resultado do design e desenvolvimento da comunidade aberta”, Gerald Pfeifer, SUSE.
O anúncio do Canonical de que eles trabalharam com outras distribuições atraiu algumas críticas de alguns membros da comunidade de código aberto. Os desenvolvedores Fedora não gostaram deste anúncio e criticaram a Canonical afirmando que não havia nenhuma colaboração entre os dois projetos.
Quando seguimos com o fundador da Canonical, Mark Shuttleworth, para perguntar sobre estas acusações, ele respondeu, “Fizemos um resumo com a equipe de desktop da Red Hat e estamos sempre abertos a trabalhar com todas as distribuições Linux para habilitar Snaps.”
Isso acabou sendo notícia para a Red Hat, no entanto, que pastoreia a distribuição Fedora.
“Enquanto trabalhamos com a Canonical em várias comunidades, ficamos tão surpresos quanto todos os outros quando anunciaram nosso envolvimento nesta iniciativa em particular. Estamos abertos a mais discussão sobre isso, e para ver como a comunidade Linux em geral quer trabalhar em conjunto”, disse Hellekson.
Os oficiais do SUSE também minimizaram qualquer colaboração. “A Canonical e a SUSE não estão atualmente envolvidas no desenvolvimento em torno da colaboração em Snaps e, de fato, parece que isso não foi o resultado de um projeto e desenvolvimento aberto da comunidade”, disse Pfeifer.
O que parece ter acontecido é que a Canonical trabalhou com alguns desenvolvedores, talvez apenas um punhado, de outros projetos e eles ajudaram no empacotamento de Snaps para outras distribuições”.
Canonical não é Perfeito
Parte do pushback que a Canonical pode ter obtido pode ser um subproduto de como ela faz negócios.
Para uma, outras empresas Linux, como Red Hat e SUSE, mantêm uma separação muito clara de poderes quando se trata de Fedora e openSUSE. O Fedora e o openSUSE são projetos bastante independentes, orientados pela comunidade, onde as decisões são tomadas pelos membros da comunidade e não pelas empresas patrocinadoras.
Em contraste, o Ubuntu é um produto canônico que por acaso também é um projeto comunitário. Devido a isso, ao contrário do openSUSE e Fedora, a Canonical tem controle direto sobre o Ubuntu. Já aprendemos no caso do próprioCloud; é realmente difícil manter um equilíbrio entre as necessidades da comunidade e da empresa; muitas vezes acaba num desastre como o próprioCloud.
>
A questão surge de como se ‘trabalha’ com um projeto?
Também, muitos sentem que há uma falta de transparência com o Ubuntu. Às vezes, muitos dos principais colaboradores do Ubuntu têm expressado frustração enquanto a Canonical mantinha grandes anúncios em torno do Ubuntu, escondidos até mesmo dos membros centrais. Os membros do Ubuntu não tinham nenhuma pista sobre o Ubuntu para Windows ou o malfadado projeto Edge.
“Nós não seguramos as coisas”, o CEO da Red Hat Jim Whitehurst respondeu a uma pergunta sobre a abordagem dessa empresa ao código aberto. “Quando construímos coisas, não as escondemos das pessoas para fazer uma grande revelação e dizemos ‘aqui está o código’. Nós não fazemos isso. Nós trabalhamos em comunidades desde o primeiro dia, o tempo todo. Eu acho que tentamos ser realmente bons participantes, e acho que isso vem através”
Acima dessas diferenças, a Canonical também é conhecida por fazer alguns passos errados quando se trata de liberar informações. Este certamente parece ser o caso para anunciar suporte a distribuições cruzadas para o Snap; a frase que irritou os desenvolvedores do Fedora foi “Desenvolvedores de múltiplas distribuições Linux”. Para ser claro, a Canonical nunca declarou explicitamente em seu comunicado de imprensa que trabalhava com o Fedora. E baseado nas informações que coletamos, não houve nenhum envolvimento “oficial” com distribuições Linux como Fedora, Red Hat, SUSE ou outras.
Que dito isso, a questão surge de como se ‘trabalha’ com um projeto? Se um desenvolvedor que trabalha em um aplicativo colabora com um desenvolvedor Ubuntu, um desenvolvedor Fedora e um desenvolvedor openSUSE para trazer esse aplicativo para essas plataformas, seria errado dizer que o desenvolvedor trabalhou com múltiplas distribuições para trazer o aplicativo para elas? Ou será que o desenvolvedor precisa de envolvimento oficial com os líderes do projeto dessas distribuições para poder fazer tal afirmação? É uma comunidade distribuída, de código aberto, afinal.
Aonde Snap?
A grande questão é, Snap será oficialmente adotado por outras distros? É aí que as coisas ficam um pouco complicadas. Torna-se uma questão tecnológica e política.
Primeiro de tudo, Snap não é a única solução por aí. Há muitos projetos que tentaram oferecer ecossistemas de embalagens agnósticas distro para os ecossistemas Linux. Mas pode ser difícil encontrar consenso dentro do mundo da distro Linux. Há o AppImage e o Flatpak, que oferecem alternativas adequadas ao Snap; estes projectos existem há muito mais tempo do que o Snap.
Então porque é que a Canonical não adoptou estas soluções em vez de iniciar o Click ou o Snap?
“Olhámos para ele, e descobrimos que o AppImage funciona perfeitamente para aplicações desktop ‘leaf-node'”, disse Shuttleworth. Uma aplicação leaf-node é aquela que não precisa de se integrar com qualquer outra aplicação. O Snap foi projetado mais para embalar aplicações com dependências e aplicações relacionadas. “Snaps tem uma gama de capacidades para descrever essas conexões – interfaces, plugs e slots, bem como arquivos compartilhados e assim por diante”.
Além disso, Shuttleworth nos disse que o Snap foi projetado para níveis mais altos de segurança em comparação ao AppImage, em parte porque a equipe que trabalha no telefone celular estava focada na segurança e eficiência, e em parte porque o Snap usa novas capacidades de kernel.
Flatpak supostamente foi vítima da rivalidade entre a Canonical e a Red Hat, já que estava sendo desenvolvido pelo pessoal do Fedora. Quando eu perguntei, Shuttleworth o descartou como um projeto sendo desenvolvido por um único desenvolvedor.
Isso explica porque a Canonical foi adiante com Snap.
Agora, outras distros irão adotá-lo? Os desenvolvedores Fedora já declararam que não vão usar o Snap. Um desenvolvedor Fedora escreveu na lista de discussão, “Nós, é claro, não temos planos de adotar o Snappy no Fedora, e na verdade, vários desenvolvedores Fedora estão trabalhando em uma solução concorrente, Flatpak”
Red Hat anteriormente abraçou um projeto Canonical para inicialização de sistemas chamado Upstart. Hellekson disse, “Estes são dias muito iniciais para todos estes esforços de empacotamento, e esperamos trabalhar com todas as comunidades relacionadas para tornar a vida o mais fácil possível para os usuários do Linux”, “
Além da rivalidade entre a Red Hat e a Canonical, há algumas questões técnicas que podem desencorajar outros projetos de colaborar no Snap”. Uma dessas razões é que os desenvolvedores têm que assinar um CLA (Contributor License Agreement) se eles contribuírem para o projeto Snap. Michael Hall, um desenvolvedor da Canonical, disse que “um CLA é necessário quando um desenvolvedor quer contribuir para o próprio projeto Snap”. Não é necessário CLA para criar ou distribuir Snaps de aplicativos”
CLAs permitem que a Canonical altere a licença do projeto. Isso é benéfico para a Canonical, pois eles podem relicenciar um projeto, permitindo que ele seja usado com licenças não-livres ou incompatíveis. Desenvolvedores normalmente não gostam de CLAs.
Frank Karlitschek do Nextcloud nos disse que está terminando os CLAs do Nextcloud, pois ele sentiu que os CLAs não têm uma boa reputação dentro da comunidade de código aberto.
Quando perguntamos à Red Hat se os CLAs iriam diminuir a colaboração em torno do Snap, Hellekson disse, “Acordos de Licença de Contribuinte nos dificultam a participação. Acreditamos que o licenciamento de código aberto é uma abordagem melhor e mais inclusiva”.
A resposta da SUSE foi muito parecida. Pfeifer disse: “Os engenheiros e funcionários da SUSE continuam a contribuir para uma infinidade de projetos de código aberto, tanto no tempo da empresa como no nosso próprio, e onde necessário assinamos CLAs”. No entanto, onde e quando iniciamos ou influenciamos projetos, tentamos nos manter afastados dos CLAs. Geralmente não gostamos de CLAs que atribuem um copyright que permite que as organizações re-licenciem código aberto usando uma licença de código não aberto”
Quando perguntamos ao Shuttleworth se ele consideraria abandonar CLAs do Snap para obter um suporte mais amplo de outras distros, ele começou explicando porque os CLAs são bons, mas depois também disse que “se isso fizesse diferença, então sim, encontraríamos uma maneira de abandoná-lo”.”
E então havia um?
O tempo, maturidade, popularidade e superioridade técnica de um sobre o outro pode nos deixar com uma solução. Já vimos isso antes com Upstart e systemd, onde o systemd surgiu como uma tecnologia superior e se tornou o padrão nas três principais distros Linux: Ubuntu, RHEL e SUSE.
Em ambos os casos, ambas as tecnologias estão em estágios muito iniciais de desenvolvimento, e é difícil dizer qual projeto terá sucesso. No entanto, é bastante claro que no mundo centrado em contêineres, o Linux precisa de um novo mecanismo de entrega de aplicativos.
Muitas empresas e comunidades têm expressado apoio a soluções como o Snap. A Samsung e a Dell juntaram-se à Canonical na chamada de imprensa e afirmaram a necessidade de tal solução. No lado do desktop, projetos como LibreOffice e Firefox já expressaram suporte ao Snap.
Time dirá se o Snap será adotado fora do Ubuntu ou não. Seja qual for o futuro do Snap, devemos dar o devido crédito à Canonical por empurrar o envelope, forçando o resto da comunidade Linux a finalmente se concentrar na solução de um problema com o qual ou nos tínhamos tornado tão confortáveis ou, talvez, nunca tivemos a motivação de resolver.
CoreOS e Red Hat são patrocinadores do The New Stack.