Primeiramente, usei o Ubuntu por muito tempo… já usei o Fedora, Debian e o openSUSE; tudo em desktop (não necessariamente nessa ordem) 😉 Particularmente, não sou de ficar testando distro aqui outra acolá. Todas as distros que citei permaneci, pelo menos, por mais de 6 meses; apenas atualizando de versão e fazendo upgrades necessários. Contudo, com o lançamento da versão 16.04 LTS do Ubuntu resolvi pensar sobre a possibilidade em poder ter um sistema sempre atualizado e que não precisasse aguardar tanto tempo, no mínimo 2 anos, para ter kernel e pacotes novos testados e estáveis no sistema.

Ubuntu LTS

Meu primeiro contato com o Linux Desktop foi com o Ubuntu ( versão 9.04 \o/ ). Acompanhei as principais mudanças à cerca do ambiente proposto pela Canonical, empresa mantenedora do Ubuntu. Entre elas, a alteração do Gnome pelo Unity (um divisor de águas na interação humano computador). Particularmente, gosto e gostei da proposta… claro, como a maioria tive resistências por parte da “nova cara” do sistema.

Suportes prolongados e estabilidade do sistema são pontos fortes das versões LTS (“Long Term Support”) do Ubuntu, lançadas periodicamente a cada 2 anos. Assim, nunca usei, não sendo em testes, versões intermediárias do Ubuntu (versões que são lançadas semestralmente e que possuem suporte reduzido em relação a LTS). Tecnicamente, são denominadas de “Fixed Releases” – Atualizações relevantes do sistema são feitas nesses períodos, já pré-determinados.

Por isto, sempre optei por versões LTS. E quando tive informações e certeza sobre a estabilidade da versão LTS mais nova lançada, fazia o upgrade de versão.

Assim, traçando uma linha de tempo das atualizações de versões que fiz, somente mudei de versão, do Ubuntu, 3 vezes (10.04, 12.04 e 14.04 LTS); desde que comecei a usá-lo (Ubuntu 9.04). Nesse meio tempo, usei outras distros para Desktop… Fedora, Debian e openSUSE 😉 Ou seja, um ponto forte para tê-lo usado por tanto tempo… “menos mudança de versão, menos stress”.

Contudo, mudar de versão de sistema somente 3 vezes ao longo de 6 anos pode ser pouco… já que as atualizações na versão não mudavam bruscamente as versões das aplicações e, principalmente, do kernel Linux. E isso, vejo como ponto negativo… ter versões mais novas das aplicações ou do kernel Linux somente quando a nova versão LTS estiver lançada e estável. Para você ter uma ideia, colocando o lançamento de versões de kernel e todas as suas melhorias, num intervalo de 2 anos, de lançamento de uma versão LTS, o kernel Linux foi atualizado diversas vezes:

Versões do Ubuntu / Kernel Linux

9.04 – Linux 2.6.28
9.10 – Linux 2.6.31
10.04 – Linux 2.6.32
10.10 – Linux 2.6.35
11.04 – Linux 2.6.38
11.10 – Linux 3.0
12.04 – Linux 3.2
12.10 – Linux 3.5
13.04 – Linux 3.8
13.10 – Linux 3.11
14.04 – Linux 3.13
14.10 – Linux 3.16
15.04 – Linux 3.19
15.10 – Linux 4.2
16.04 – Linux 4.4

É claro, é possível mudar/atualizar o kernel Linux sem precisar esperar essas versões serem lançadas. Contudo, alterações desse nível não são recomendadas já que a versão do sistema usada não está preparada para rodar com outra versão de Kernel Linux, deixando a cargo do usuário prepará-lo para tal. Convenhamos, não seria para qualquer usuário fazer isso; principalmente, para um usuário que procurou no Ubuntu as facilidades oferecidas pelo sistema.

Além do mais, versões de softwares/programas ficam “presos” a versão usada. Assim, o Ubuntu criou e ofereceu um recurso “libertador” (ao mesmo tempo arriscado) chamado PPA. Nele você pode instalar/atualizar programas que não estão nos repositórios oficiais da comunidade Ubuntu. O “risco” está em inserir repositórios de desenvolvedores terceiros que não fazem parte da comunidade oficial do Ubuntu… assim, sempre é importante saber a procedência de tal desenvolvimento #ficadica

Na versão mais nova do Ubuntu (16.04 LTS) o recurso snap foi lançado. Ele é um novo tipo de pacotes que nos permite instalar programas de maneira muito simples, sem ter de procurar as dependências.

Por fim, vejo a Canonical (mantenedora do Ubuntu), nos últimos anos, muito voltada para o lado do mercado e dispositivos móveis (Ubuntu Phone), vide parceria, nunca imaginada antes, com a Microsoft; que permitiu o Windows executar um bash Linux “nativamente” no seu sistema.

Nada contra (mesmo sendo muito criticada pela comunidade Linux), mesmo com diversos outros assuntos polêmicos conflitantes com a comunidade Software Livre (backdoors, pesquisa online com a Amazon e outros). Mas, o que me fez mudar de distro Linux não foi isso…em resumo, foi a rigidez do modelo “Fixed Release” adotado pelo Ubuntu e muitas outras distros Linux. Assim, apenas decidi usufruir do meu direto e benefício ao usar software livre, que é ser “livre” para escolher qual software/sistema usar \o/

OpenSUSE Tumbleweed

Por que o OpenSUSE? E por que o Tumbleweed? 😉

Nos últimos anos o projeto OpenSUSE tem ganhado vários adeptos, aumentando significativamente a comunidade de usuários. Conforme ranking do Ditrowatch, o OpenSUSE é hoje a quarta distribuição mais popular do mundo. Todo esse crescimento se deve as constantes novidades lançadas pelos mantenedores do OpenSUSE.

O openSUSE era patrocinado pela Novell – foi vendida pra Attachmate e posteriormente para Microfocus, que fez do SUSE uma unidade independente; atualmente o openSUSE é patrocinado pela SUSE. Promovendo o uso de Linux por toda a parte, a comunidade openSUSE disponibiliza, gratuitamente, uma das versões Linux mais usadas em todo mundo.

Diante disso, a comunidade openSUSE lançou 2 grandes projetos – o LEAP e o Tumbleweed. Um com a base do SUSE Linux Enterprise – SLE – a versão comercial e com suporte técnico do SUSE – tendo suporte LTS; e outro com a adoção do modelo “Rolling Release” (modelo distinto a “Fixed Release”) do openSUSE. Em resumo, o modelo “Rolling Release” visa propiciar versões de atualizações evolutivas contendo as últimas versões estáveis, ao invés de observar ciclos de lançamentos periódicos rígidos (“Fixed Release”).

Outro aspecto interessante do openSUSE, é o uso da plataforma OBS (Opensuse Build Service) – voltado para a manutenção de pacotes, é uma plataforma para desenvolvimento de distribuições que provê aos desenvolvedores uma infraestrutura transparente para o empacotamento de aplicativos para a maioria das distribuições. Diferentemente ao Launchpad da Canonical (Ubuntu), em que a maioria dos fontes oficiais são importados do Debian e construídos a partir disso, o openSUSE mantém todos os pacotes oficiais no OBS.

Em resumo, o modelo “Rolling Release” sempre me chamou atenção; visto os benefícios em manter um sistema sempre atualizado sem aguardar mudanças periódicas pré-estabelecidas. Visando esse modelo e querendo sair do universo Ubuntu, eu poderia usar o Arch Linux (distro mais conhecida que adota o modelo Rolling Release); por exemplo. Ou poderia “transformar” o Ubuntu em Rolling Release também 😉

Assim, o openSUSE foi escolhido por conta da estabilidade dos repositórios e solidez da comunidade de desenvolvedores. Além claro, de ser um sistema robusto (Yast, zypper) e mais seguro (firewall iptables pré-configurado). E a escolha do projeto Tumbleweed, foi por conta da adoção do modelo “Rolling Release” em um sistema que já me agradava e que agora oferece, oficialmente, o suporte de atualizações evolutivas \o/

Nova experiência

Resolvi usar o Gnome 3.20 (tem suporte ao KDE 5, também). Kernel Linux mais recente estável e aplicações atualizadas 😉 Contudo, nem tudo “são flores”. A mudança foi radical… realmente. Logo no momento da instalação, o Sistema de Arquivos oferecido, por padrão, é o BtrFS (ainda oferece suporte ao Ext3, Ext4 e outros):

O Gerenciamento de pacotes é feito pela ferramenta de linha de comando zypper e interface gráfica Yast (inclusive, vai muito além de um gerenciador de pacotes gráficos). Além disso, nada de repositórios “main”, “security”… agora são OSS, non-OSS e UPDATE. Possuindo, também, repositórios não oficiais; como o Packman.

E, finalmente, o projeto Tumbleweed possui algumas ressalvas importantes. Como ele recebe rotineiramente atualizações do kernel, aplicações que são sensíveis as alterações do header do Kernel; como o VirtualBox, foi decidido pela comunidade não oferece suporte oficial a ele no repositório principal do Tumbleweed – mesmo tendo suporte as arquiteturas de máquina virtual VMware e Hyper-v. A cada mudança do kernel, é preciso recompilar a versão do VirtualBox :/

Além disso, conforme nota do projeto, os usuários que dependem de drivers gráficos proprietários NÃO devem usar a versão Tumbleweed, salvo se estiverem familiarizados com a atualização desses drivers a partir do fonte; fazendo isto por conta própria :/

E se mesmo com todas as ressalvas e novidades, você desejar usá-lo também; segue link de download da ISO oficial 😉