OpenSUSE recomenda testar o MicroOS para se adaptar ao futuro ALP, que será basicamente um MicroOS Enteprise (pelo que entendi).
Continuando minha série de teste com o MicroOS no desktop, hoje vou revisitar o sistema, verificar como está o uso do desktop em geral.
Vou instalar em uma VM com 4GB RAM + 25GB HD.
Instalação
Levou aproximadamente 10 minutos (instalação mais rápida do openSUSE comparando o Leap e Tumbleweed tradicionais)
obs: escolhi GNOME Desktop pois já está em “RC”.
Configuração inicial
obs: o sistema não tem animação de boot
Configuração Automática inicial
Instala Firefox e alguns app’s diretamente do Flathub automaticamente:
App’s padrão / Desktop
Por algum motivo está com 2 app’s de monitor do sistema. Apesar de vir bem enxuto achei a escolha padrão meio estranha com Tweaks, Uso (monitor), atualizador de pacotes e fontes de programas (coisa que a GNOME Software já faz).
O sistema vem apenas com 1 wallpaper sem vesão claro/dark:
Também não vem com as imagens padrão do GNOME na escolha do usuário:
Vem com algumas extensões padrão do GNOME e uma incompatível, porém todas desativadas:
Quando se vê o tempo de inicialização se tem uma ideia de o porque o nome “MicroOS” pois vem com pouca coisa habilitada por padrão, demora aproximadamente 5.2s de boot com SSD:
GNOME Software
Aqui um ponto fraco, falta de integração do transactional-update para instalação de .rpm’s com a GNOME Software, mas como já adiciona o Flathub no início, você terá fácil acesso a mais de 1700 app’s + app’s em .rpm que a loja mostrar.
Na instalação de pacotes .rpm’s irá ocorrer um erro por conta da falta de integração falada anteriosmente. Mas poderá instalar via terminal normalmente.
A loja parece dar prioridade para os .rpm’s (na seleção de fonte do pacote da GNOME Software) mesmo não funcionando:
Também não é possível verificar repositórios de programas:
Atualização do sistema
A atualização via GNOME Software falha pela falta de integração com transactional-update:
Com o app “Atualizador de pacotes” também falha:
Mas via CLI funciona normalmente, com o comando:
sudo transactional-update dup
Uso de HD inicial (com Flatpak’s instalados):
4.5GB uso padrão. Não vem com compressão no BtrFS.
Transactional-update
O novo “gerenciador de pacotes” do MicroOS que faz uso do Zypper + Btrfs está de volta:
Veja a documentação para mais detalhes e comandos.
Testando o rollback.
Esta é uma função muito importante e útil, assim como no Silverblue com OSTree ou qualquer outro sistema que use BtrFS com snapshots, te permite voltar ao estado anterior do sistema, caso algum update quebre algo ou o usuário quebre algo.
O sistema não vem com ferramenta gráfica para gerenciar rollbacks, irei usar o temrinal.
Primeiro verificamos a lista de snapshots:
sudo snapper listNo meu caso, ainda não foi criado nenhuma snapshot, pois não foi instalado nenhum .rpm ou atualizado o sistema.
A cada alteração, com transactional-update, é criado um novo snapshot, então vamos aqui instalar um .rpm:
sudo transactional-update pkgs install gimp
O processo foi relativamente rápido, quase como usar um gerenciador de pacotes normal (creio que um pouco mais rápido que rpm-ostree). E no final fala para reiniciar para evitar perda de dados e usar o pacote instalado ou a mudança feita:.
Ao reiniciar estava lá:
Então verificando novamente via snapper list, já estava no novo snapshot (2) e ao que parece adicionou apenas a diferença do que foi modificado em espaço de disco:
Finalmente fazendo o rollback com o comando:
sudo transactional-update rollback 1obs: o comando foi praticamente instantâneo.
Ao reiniciar, voltou ao snapshot anterior, mantendo o mais atual salvo.
Não tenho certeza de quantos snapshots ele mantém salvo, mas é possível deletar com snapper delete.
Versões dos pacotes
O MicroOS se baseia no Tumbleweed, então será um sistema moderno e atualizado.
Driver Nvidia se encontra via repositórios do obs:
https://software.opensuse.org/package/nvidia-open-gfxG06
Detalhe talvez relevante: MicroOS usa SELinux
Vem com Toolbox por padrão, que cria container do Tumbleweed apenas com o toolbox enter:
Concluindo
Falta vários “pequenos” polimentos no desktop, apesar de já estar em fase “RC” já demonstrou muita evolução.
A combinação das tecnologias Zypper + BtrFS que o transactional-update utiliza parece estar muito otimizada, tanto na velocidade quando no espaço de disco.
Como podemos ver aqui, o MicroOS está muito bem configurado com BtrFS, bem diferente de quando testei no Leap.
A atualização é atômica, mas o download dos pacotes são feito como no openSUSE tradicional, pacote por pacote, baixando os binários inteiros, diferente do OSTree que baixa apenas as partes que mudaram. O deltarpm tenta economizar mas não é tão eficiente.
Não tenho certeza das limitações do MicroOS, comparando com o Silverblue, no que diz respeito a compatibilidade de .rpm’s. Por exemplo, no Silverblue se algum .rpm tentar modificar uma parte imutável/sensível ao sistema OSTree não irá instalar, já no MicroOS não tenho certeza se irá permitir, mas me parece ser mais “liberal” neste quesito.
O MicroOS roda em sistema de arquivos somente leitura, então se algum .rpm / “script de instalação obscuro” precisar modificar algo no sistema de modo “live” para funcionar, talvez não funcione, assim como no Silverblue.
Trazer Flathub e automaticamente já instalar o Firefox Flatpak é um baita ponto positivo, se continuar assim entrará na minha lista de sistemas mais recomendados para iniciantes.
Viu algum erro ou gostaria de adicionar alguma sugestão/atualização nesta matéria? mande para fastos2016@gmail.com
Fast OS 
Deixe um comentário