Introdução aos sistemas Linux imutáveis

 (dataswamp.org)
3 pontos por GN⁺ 2023-09-19 | 1 comentários | Compartilhar no WhatsApp
  • Distribuições Linux imutáveis preparam upgrades fora do sistema em execução e aplicam na próxima inicialização, oferecendo um modo de operação que permite reverter em caso de falha
  • Apesar do nome “imutável”, várias áreas do sistema ainda podem mudar, e a característica comum real está mais próxima de atualizações transacionais com rollback
  • NixOS e Guix se concentram em configuração declarativa e armazenamento somente leitura, enquanto a família OSTree, o MicroOS e o Vanilla OS abordam isso respectivamente com /usr, snapshots do btrfs e partições raiz A/B
  • As vantagens são manter o sistema estável mesmo durante mudanças de pacotes e poder desfazer problemas, mas ainda existem limitações como necessidade de reinicialização, conflitos com ferramentas de gerenciamento de configuração e dificuldade para rastrear mudanças
  • A novidade não está no snapshot em si, mas em aplicar mudanças em um ambiente não ativo, integrando isso ao bootloader e a ferramentas de usuário para facilitar o uso

O alcance real do nome “imutável”

  • Imutabilidade originalmente significa um objeto que não muda, mas ao aplicar isso a sistemas operacionais a definição logo se torna ambígua
  • Um Linux LIVE-CD parece imutável porque sempre inicializa com os mesmos programas e a mídia em disco é somente leitura, mas durante a execução ainda é possível criar arquivos e diretórios ou instalar pacotes
  • Hoje, para normalmente ser chamada de distribuição Linux imutável, ela precisa em geral cumprir três condições
    • Não realizar upgrades do sistema diretamente no sistema em execução
    • Aplicar mudanças de pacotes na próxima inicialização
    • Permitir rollback para o estado anterior
  • Cada implementação traz recursos extras diferentes, mas esses três pontos são o mínimo mais próximo do que hoje se entende por distribuição “imutável”

Diferenças entre implementações

  • NixOS / Guix

    • NixOS e Guix dependem de implementações da mesma família; o Nix apareceu pela primeira vez em 2003, e o gerenciador de pacotes Guix foi derivado do Nix no início da década de 2010 com o objetivo de ser 100% software livre
    • Os dois sistemas diferem bastante dos sistemas tradicionais da família Unix e adotam a imutabilidade como princípio central
    • Todos os pacotes e arquivos gerados em build são armazenados como entradas exclusivas em um diretório especial somente leitura que só o gerenciador de pacotes pode usar
    • O próprio sistema operacional é um resultado do gerenciador de pacotes, e o usuário descreve o estado desejado do sistema em uma configuração declarativa
    • A configuração inclui usuários, shell, pacotes instalados, serviços em execução e suas definições, partições a montar e opções relacionadas
    • Como os módulos fornecem valores padrão, ao criar um usuário não é necessário definir manualmente UID, GID, shell e diretório home
    • Arquivos como /etc/fstab e /bin/sh também são somente leitura, e para alterá-los é preciso passar pelo gerenciador de pacotes
    • A troca de configuração se parece mais com uma alteração de link simbólico, então pode acontecer imediatamente, e no boot é possível escolher uma configuração anterior para fazer rollback
    • Exceto pelo diretório especial de armazenamento, áreas como /home, /etc e /var podem ser alteradas; é possível substituir links simbólicos do sistema por outros, mas não modificar o código-fonte original
    • O NixOS é considerado uma boa implementação, mas por ser muito diferente dos sistemas existentes sua adoção ainda é baixa apesar das vantagens

  • Endless OS

    • Endless OS foi um dos primeiros sistemas operacionais imutáveis lançados para usuários comuns e buscava oferecer um sistema robusto que pudesse ser usado também em países com cobertura limitada de internet ou energia elétrica
    • É baseado em Debian, mas implementa imutabilidade com OSTree
    • O OSTree gerencia a imagem central do sistema e adiciona camadas por cima, como pacotes, permitindo preparar uma nova imagem do sistema para a próxima inicialização
    • As mudanças de pacotes são aplicadas a uma nova versão do sistema que será usada no próximo boot, e durante a inicialização é possível voltar para a versão anterior
    • As partições em geral são graváveis, mas /usr, que é a área de pacotes controlada pelo OSTree, é montado como somente leitura
    • Não há rollback para /etc
    • Os programas para o usuário são instalados com Flatpak, reduzindo a necessidade de reiniciar a cada instalação de pacote novo
    • O desktop GNOME modificado tem aparência semelhante a um menu de smartphone e busca ser amigável para usuários não técnicos
    • Instalar ferramentas de DevOps não é muito prático, mas também não é impossível

  • Fedora Silverblue

    • Fedora Silverblue faz parte da continuidade do Project Atomic, que tentou tornar Fedora / CentOS / RHEL imutáveis
    • Usa rpm-OSTree, que aplica mudanças de pacotes RPM sobre o OSTree
    • O sistema é composto por uma única imagem central por release e por camadas extras de pacotes adicionadas sobre ela
    • É possível listar as camadas de pacotes instaladas, e ao remover um pacote toda a pilha é recriada para que não sobrem resíduos após a remoção
    • Esse processo de recriação é muito lento
    • Mesmo instalando um pacote, ele não é aplicado ao sistema atualmente inicializado, então em geral é preciso reiniciar; no boot, pode-se escolher a versão anterior do sistema
    • O rpm-OSTree oferece um recurso para mesclar temporariamente as mudanças do próximo boot ao sistema ativo por meio de um overlay tmpfs
    • A política de montagem é somente leitura, exceto para /etc, /root e /var, e o diretório home fica por padrão em /var/home, o que pode destoar do esperado
    • Como /etc não é gerenciado pelo rpm-OSTree, ele não entra em rollback
    • /usr/local é um link simbólico para um diretório dentro de /var, o que facilita injetar mudanças do usuário mesmo sem arquivos RPM
    • Como instalar pacotes é lento e exige reboot, recomenda-se usar Flatpak ou toolbox
    • O toolbox cria contêineres Fedora sem privilégio de root para permitir o uso de bibliotecas e ferramentas de desenvolvimento no terminal

  • OpenSUSE MicroOS / Aeon

    • OpenSUSE MicroOS é uma variante imutável do rolling release OpenSUSE Tumbleweed e usa uma implementação própria
    • Todo o sistema, exceto alguns diretórios como /home e /var, fica sobre snapshots do btrfs
    • Quando uma mudança no sistema é necessária, o snapshot atual é clonado em um novo snapshot, a mudança é aplicada nele e ele passa a ser usado no próximo boot
    • Diferentemente dos sistemas baseados em OSTree, o /etc também faz parte do snapshot e, portanto, pode ser revertido
    • É possível usar um shell dentro do novo snapshot para alterar qualquer arquivo do sistema de arquivos, o que é útil para tarefas como injetar arquivos para corrigir problemas de driver
    • No entanto, essas mudanças não são rastreadas, então é difícil garantir se o sistema continua em um estado “puro”
    • As mudanças são feitas com o comando transactional-update, que permite adicionar ou remover pacotes ou abrir um shell dentro do novo snapshot para fazer o que for necessário
    • O /etc entra no snapshot, mas está sempre acessível para leitura, então se ele for alterado no sistema ativo e depois um novo snapshot for criado, essa mudança será herdada imediatamente
    • A abordagem padrão assume reinicializações diárias após as atualizações e, como é um rolling release, há updates todos os dias; antes de reiniciar, não se obtém o benefício dos novos pacotes
    • A reinicialização automática pode ser desativada
    • Assim como no Silverblue, o recurso para aplicar mudanças ao sistema ativo ainda é experimental e não está utilizável
    • Em vez disso, recomenda-se usar distrobox para instalar ferramentas de usuário em contêineres sem root de várias distribuições

  • Vanilla OS

    • Vanilla OS é um sistema mais novo dessa família imutável, baseado em Ubuntu e com planos de migrar em breve para uma base Debian
    • A imutabilidade é implementada com ABroot
    • O ABroot usa uma partição raiz A, uma partição raiz B e uma partição para dados persistentes, como /home e /var
    • O fluxo de boot e mudanças funciona assim
      • O primeiro boot é feito a partir da partição A, que é montada como somente leitura
      • Mudanças no sistema, como novos pacotes ou alterações em arquivos de /etc, são aplicadas à partição B, e também podem ser aplicadas ao vivo com overlay tmpfs
      • Após reiniciar, o sistema inicializa pela partição B e, se tudo der certo, o ABroot verifica as diferenças entre A e B e aplica em A as mudanças feitas em B
      • Quando não há novas mudanças, A e B permanecem sempre idênticas
    • A desvantagem é que o rollback só é possível até antes do boot na nova versão
    • Depois de iniciar a nova versão, as mudanças também são aplicadas à partição do boot anterior, então o rollback deixa de ser possível
    • Essa abordagem é útil principalmente para desfazer upgrades com falha ou mudanças testadas ao vivo
    • O Vanilla OS oferece o gerenciador de pacotes apx
    • O apx é uma ferramenta criada pelo autor do distrobox e permite que usuários sem root instalem pacotes de várias distribuições, como Arch Linux, Fedora, Ubuntu e Nix, integrando-os como se fossem instalações locais
    • Vanilla OS, ABroot e apx ainda são projetos jovens e um pouco brutos

  • Alpine Linux com LBU

    • O Alpine Linux pode montar uma configuração próxima da imutabilidade com o comando lbu
    • Ele usa o instalador do Alpine como sistema básico de boot e cria um tarball de “configuração salva”, que é aplicado automaticamente na inicialização
    • A cada boot, os diretórios são extraídos novamente e os pacotes são reinstalados, enquanto tudo permanece totalmente gravável na memória ativa
    • O sistema sempre começa limpo e então recebe mudanças por cima, permitindo rollback das alterações e um recomeço do zero
    • Isso não cumpre completamente a definição de imutabilidade usada antes, porque as mudanças são aplicadas sobre o sistema básico
    • Como todo o sistema fica em memória e é preciso gerenciar manualmente o que será salvo e restaurado, exige alto nível de entendimento e o arquivo pode crescer bastante
    • A documentação também é insuficiente

Vantagens e limitações operacionais

  • Vantagens

    • Quando surge um problema, é possível reverter as mudanças
    • Atualizações transacionais ajudam o sistema a continuar funcionando corretamente mesmo durante alterações de pacotes

  • Desvantagens

    • A integração com ferramentas de gerenciamento de configuração como Ansible, Salt e Puppet é muito ruim
    • Mesmo quando são adaptadas para entender como as mudanças de pacotes são aplicadas, quase sempre há barreiras ao tentar administrá-las como um sistema comum
    • Ter de reiniciar após uma mudança é incômodo, embora NixOS e Guix não exijam reboot a cada alteração
    • Sistemas baseados em OSTree não são flexíveis
      • Por exemplo, em um netbook que precisa de um arquivo extra no diretório ALSA para ter som, não dá para adicioná-lo sem criar um pacote que distribua esse arquivo
    • O rollback é quase um rollback cego, porque é difícil identificar quais mudanças existiam em cada versão do sistema
    • Programas como Nix/Guix, que precisam de diretórios no sistema de arquivos raiz, ou instalações em todo o sistema de softwares não empacotados, podem ser difíceis

Fatos e mal-entendidos sobre sistemas imutáveis

  • Em sentido estrito, a imutabilidade é quase uma falsidade, porque muitas partes do sistema ainda podem ser alteradas
  • Imutável não significa stateless
  • NixOS e Guix são vistos como implementações que já nasceram com a filosofia correta, pois rastreiam o sistema inteiro com um gerenciador de pacotes estável e permitem usar um sistema de controle de versão no código-fonte
  • A imutabilidade costuma ser associada a benefícios de segurança, mas um atacante que obtenha privilégios de root ainda pode manipular o sistema ativo e também a partição /boot
  • Nada impede a instalação de um backdoor para a próxima inicialização
  • A imutabilidade exige disciplina e manutenção
    • É preciso cuidar do versionamento
    • Programas extras como apx, distrobox e devbox precisam ser atualizados separadamente do sistema
    • No NixOS e no Guix, essa parte já é integrada

O que realmente há de novo

  • Sistemas operacionais imutáveis têm recebido atenção na comunidade de sistemas open source, mas sob o mesmo nome se misturam várias implementações e casos de uso
  • O nome “imutável” cria certas expectativas, mas na prática isso está mais próximo de atualizações transacionais para sistemas operacionais
  • Atualizações transacionais em si não são um conceito novo
    • Solaris e ZFS já permitiam escolher snapshots do sistema durante o boot
    • O FreeBSD também parece ter implementado algo parecido cerca de 10 anos atrás
    • Distribuições Linux comuns também podem permitir escolha de snapshot no boot quando usam snapshots do btrfs
  • O que realmente é novo é aplicar mudanças transacionais em um ambiente não ativo, integrar isso ao bootloader e oferecer ferramentas que facilitem o uso para o usuário
  • Como leitura complementar, recomenda-se Colin Walters em “Immutable” → reprovisionable, anti-hysteresis

Leituras relacionadas

1 comentários

 
GN⁺ 2023-09-19
Opiniões no Hacker News

  • É bom ver o Silverblue na lista, mas é uma pena que o Fedora CoreOS tenha ficado de fora
    O FCOS é um bom SO para usar em produção, evoluiu bastante desde a aquisição da CoreOS e parece um bom meio-termo: mais fácil de aprender e usar do que o Nix, sem abrir mão da imutabilidade
    O CoreOS Layering, adicionado pela equipe de desenvolvimento do FCOS, é um recurso poderoso: você define o estado do sistema com um Dockerfile, o FCOS faz o rebase para esse estado, e a configuração do servidor exige apenas uma reinicialização
    Se precisar de uma VM no próximo projeto, vale experimentar. Também criei o Bupy, uma ferramenta CLI em Python que facilita criar arquivos Butane localmente em uma workstation Linux, e há também um exemplo de execução do Paperless NGX com CoreOS Layering
    https://github.com/quickvm/bupy
    https://github.com/quickvm/fcos-layer-paperless-ngx
    https://coreos.github.io/rpm-ostree/container/
    https://github.com/coreos/enhancements/blob/main/os/coreos-l...
    https://github.com/coreos/layering-examples

    • Também gostaria de saber o que acham do Flatcar, outro projeto da família CoreOS
      A parte mais difícil para mim foi entender como usar esse tipo de projeto em ambientes bare metal. Criar imagens de VM é ótimo, mas na prática muitas vezes você quer instalar em um disco existente, ou instalar com um pool ZFS por baixo
    • CoreOS Layering parece realmente útil. Hoje uso openSUSE MicroOS em alguns Raspberry Pi e em um servidor x86_64, e um dos motivos para escolher o MicroOS foi que a instalação no Raspberry Pi era bem simples
      Fico curioso para saber o quão difícil é instalar o CoreOS em um Raspberry Pi. Alguns guias de instalação na internet parecem bem complicados

  • Outro eixo que sempre fica de fora nessas apresentações de sistemas imutáveis é a abordagem baseada em imagens
    Estou trabalhando em https://universal-blue.org/ com pessoas muito mais capazes do que eu, construindo imagens de contêiner OCI sobre a edição base do Fedora Silverblue e várias edições desktop
    Essas imagens podem ser inicializadas com rpm-ostree — ou, mais precisamente, usadas como alvo de rebase — e são uma forma de estender o sistema de maneira mais robusta do que por camadas, permitindo que qualquer pessoa herde ou aproveite facilmente as mesmas mudanças. Também é muito fácil criar sua própria imagem
    Parece que o VanillaOS e a SUSE fazem algo parecido, mas nós não somos um projeto de SO, apenas um downstream do Fedora. O suporte oficial do Fedora também está em andamento e, mesmo só com o que já funciona, pela minha experiência essa é uma das formas mais robustas e fáceis de fazer coisas como fornecer drivers da Nvidia

    • É um pouco outro assunto, mas por volta de 2009 fiquei impressionado ao ver um grande hypervisor rodando hosts de área de trabalho remota do Windows. Acho que era Citrix
      As VMs inicializavam a partir de uma imagem, e tanto a imagem quanto os discos de alterações ficavam inteiramente na RAM. Os perfis de usuário ficavam no disco rígido, mas um host de desktop para 25 pessoas inicializava em cerca de 4 segundos até ficar pronto para aceitar logins remotos
      Foi o sistema Windows menos doloroso de aplicar patches que já vi
    • Fico confuso porque achava que o Fedora Silverblue também era baseado em imagens
      Eu pensava que a instalação padrão não usava camadas, e que o layering só entrava quando você queria instalar pacotes RPM adicionais
    • Parece que o UBlue reconstrói as imagens regularmente com GitHub Actions para incorporar atualizações de pacotes. Fico curioso para saber quem paga essa conta
      Também me pergunto se as imagens são fornecidas pelo GitHub, se o GitHub cobra pelo tráfego externo, e o que acontece quando muitos usuários tentam baixar a mesma imagem

  • Tenho mais interesse em sistemas pré-configurados do que em sistemas imutáveis
    Aqui o NixOS e o Home Manager se destacam, mas o modo de configuração é realmente horrível. Quero colocar toda a configuração em controle de código-fonte e saber que o estado atual do sistema corresponde a essa configuração, e que qualquer outra alteração seja descartada ao reiniciar. Seria bom se o que mudou antes da reinicialização fosse destacado
    Pela minha experiência limitada com algo como o Silverblue, dá para configurar o sistema base, mas quando você começa a adicionar aplicativos como o Firefox acaba usando Flatpak, e não sei bem como declarar a instalação completa dos Flatpaks desejados junto com suas configurações
    Imagino que exista uma forma de instalar Flatpaks em lote e tratar o resto com dotfiles
    https://universal-blue.org/tinker/mindset/#resist-the-urge-t...

  • O problema que encontrei com Flatpak e com a abordagem imutável em geral é que não dá para fazer modificações de uma forma que o desenvolvedor não dá suporte
    Por exemplo, sincronizo meu calendário com decsync e, até onde sei, é impossível adicionar o plugin decsync ao Evolution Flatpak
    Enquanto esses sistemas imutáveis não tratarem o empilhamento de filesystems de overlay personalizados como um recurso de primeira classe para casos de uso que os desenvolvedores não podem ou não querem dar suporte, as pessoas continuarão usando sistemas mutáveis

    • O NixOS oferece exatamente esse tipo de controle de várias formas
      Alguns pacotes do nixpkgs e a maioria dos módulos do NixOS e do Home Manager expõem muitas opções para configurar plugins, pacotes adicionais etc.
      O Nix também oferece overlays e overrides para adicionar pacotes personalizados ou variantes de pacotes existentes, e até permite substituir partes de um pacote. Se isso ainda não bastar, você pode aplicar patches diretamente no código ou compilar a partir de um fork do repositório upstream
      Na prática, esse é um dos pontos de que mais gosto no Nix. Como é fácil dizer “ao compilar este pacote, substitua esta dependência pela minha versão”, acabo contribuindo com open source com mais frequência
    • Coisas como “adicionar o plugin decsync ao Evolution Flatpak” são muito comuns em software GUI no Linux
      Fora desse âmbito, a maioria dos softwares já vem com as funcionalidades necessárias. Por exemplo, o Solidworks nunca me pediu para baixar dependências opcionais, mas o FreeCAD literalmente pedia alguma coisa a cada 15 minutos sempre que eu avançava para a próxima etapa no fluxo de CAD/CAM/simulação/renderização
      https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv... também vale como referência
      O ponto central é que os “20% que todo mundo usa” nunca são os mesmos. Nos últimos 10 anos, ouvi falar de dezenas de empresas tentando lançar um processador de texto “leve” que implementa apenas 20% dos recursos, mas essa história de um jornalista escrever uma análise, procurar o contador de palavras e descobrir que ele está nos “80% que ninguém usa”, e então acabar escrevendo “programas leves são bons e inchaço é ruim, mas esta porcaria não conta palavras, então não serve para mim”, é tão antiga quanto o PC
    • Se é para chegar ao ponto de empilhar filesystems de overlay personalizados como recurso de primeira classe, acho que seria melhor simplesmente usar um sistema mutável
      Isso me lembra quando, 10 anos atrás, todo mundo correu para NoSQL e logo em seguida começou a reinventar esquemas dentro de cada projeto
    • Também é possível adicionar plugins a aplicações Flatpak, e esses plugins podem ser feitos como pacotes de extensão
      O OBS é um exemplo. No Flathub há vários plugins do OBS no formato com.obsproject.Studio.Plugin.*

  • Eu definiria assim: depois de instalar qualquer quantidade de pacotes, se em algum momento no futuro você os remover em qualquer ordem, o sistema deve ficar em um estado equivalente ao de nunca tê-los instalado desde o início
    Essa definição excluiria algumas distribuições, mas acho que essa propriedade é a parte importante do conceito

    • O ponto principal parece ser que, em sistemas voltados ao usuário, essa propriedade é praticamente impossível
      Ao remover um processador de texto ou editor de texto, você quer que todos os arquivos que escreveu também desapareçam? Ao remover um navegador, todos os arquivos baixados devem sumir também? Se não, não há uma forma confiável de distinguir quais arquivos foram criados automaticamente pelo programa e quais foram criados pelo usuário usando aquele programa
      O que foi criado durante a instalação pode ser removido facilmente, mas não todas as alterações posteriores
      Também dá para imaginar o caso de trocar a implementação de DNS e, depois, mudar o servidor DNS padrão. Ao remover o provider e voltar para a implementação anterior, é preciso escolher se o servidor antigo também deve ser restaurado ou se a nova configuração de servidor deve ser mantida. Pessoalmente, eu gostaria de trocar apenas o provider e manter o novo servidor
      Diretórios compartilhados por várias máquinas também complicam as coisas. Se /home/${USER} for uma montagem NFS ou Samba e os mesmos arquivos forem usados em várias workstations, quando um programa cria arquivos no diretório de configuração XDG e esse programa é removido de uma workstation, os arquivos de todas as máquinas também devem ser apagados? Um gerenciador de pacotes de um único sistema não tem como saber se todos os dispositivos devem ser idênticos ou se basta o diretório home ser idêntico
    • A questão é até que profundidade você quer aplicar essa propriedade
      Vale a pena olhar para estruturas de dados com representação única e estruturas de dados independentes do histórico
      Seria preciso tomar cuidado especial para que dispositivos de bloco, por exemplo SSDs, alocassem blocos independentemente do histórico
    • Essa propriedade é chamada de reprodutibilidade, e significa que a mesma configuração sempre produz o mesmo estado do sistema
    • Gostei dessa definição
      Também daria para dizer que o conjunto de pacotes forma uma lattice, e que, independentemente do caminho percorrido para chegar a qualquer subconjunto de pacotes, existe apenas um estado

  • Uso o Fedora Silverblue desde o lançamento, e isso é definitivamente o futuro
    Acho que todo mundo deveria usar ostree

    • Senti que o Silverblue não era flexível o bastante para computadores pessoais
      Talvez seja eu que use Linux de um jeito meio improvisado, mas não ter permissão de escrita em pastas como /usr ou /bin me deixava maluco mais ou menos uma vez a cada duas semanas
      Por exemplo, um script escrito por um usuário do Ubuntu estava procurando uma biblioteca com nome e localização no estilo do Ubuntu, enquanto o Fedora usa outro nome para essa biblioteca. Numa situação dessas, meu instinto é criar um link simbólico com o nome do Ubuntu apontando para a biblioteca gerenciada pelo RPM do Fedora
      Mas, na prática, para fazê-lo funcionar, eu tinha que fazer fork do script, fazer com que ele compilasse localmente, ajustá-lo para procurar os dois nomes de biblioteca, rodar testes locais, enviar um PR upstream etc. Algo que normalmente terminaria com uma linha no shell virava uma tarefa de 90 minutos
    • Estou usando há 1 ano e é muito bom. Fico me perguntando se a Red Hat sabe o que tem em mãos. Não só o Silverblue, mas o próprio Fedora também
      Li em uma resposta no Quora uma estimativa de que o orçamento de desenvolvimento do Windows OS, com base em salários, seria de cerca de US$ 18 bilhões. Imagine a Red Hat investindo US$ 2 bilhões no Fedora para transformá-lo no Firefox do mundo dos sistemas operacionais de desktop; só conseguir 10% de participação contra a Microsoft já seria enorme
      Chegou até aqui com tão poucos recursos, sobre milhares de pacotes open source. Esse dinheiro poderia ser usado para manter esses projetos vivos e patrociná-los durante o desenvolvimento. Funcionários da Red Hat já estão envolvidos em muitos deles
    • Gosto da ideia do ostree, mas, pelo que vi por alto, ele não parece tão amigável quanto o Docker para usuários comuns ou intermediários. Um usuário individual consegue aprender Docker em uma tarde
      Não ficou claro como se chega ao ponto de “distribuir uma distribuição Debian como snapshots ostree”
      Fico me perguntando se isso foi projetado só para administradores de sistemas profissionais ou construtores de sistemas
    • Se você já usou Nix, fico curioso para saber como é a comparação
      Não usei Silverblue, mas Nix também parece o futuro
    • No momento uso Ubuntu nos servidores e vi que há ostree no repositório, mas ainda não consegui testar
      Se possível, gostaria de começar a versionar o sistema atual exatamente como ele está. Se isso for difícil demais ou impossível, penso em migrar o servidor para Silverblue algum dia. Gosto muito da ideia do ostree

  • Neste verão, fiquei fascinado pelo Tinycore
    Ele complementa bem a filosofia de segurança “um OS, uma função” por trás de Qubes, Tails e Whonix, de que falei aqui alguns dias atrás
    Como é extremamente leve, dá para subir em poucos segundos uma VM para servidor de e-mail, outra para banco de dados e outra para firewall/roteador
    O próprio Tinycore é imutável, então basta colocar os “pacotes” e as configurações no vdisk e marcá-lo como somente leitura. Um script Virsh cuida de iniciar e encerrar o “serviço”, e cada serviço é uma instância do Tinycore
    É divertido e, até agora, robusto, mas ainda não tenho certeza se colocaria isso em produção de alguém

    • O TinyCore sempre fica de fora dessas introduções a Linux imutável. Ele existe há muito tempo e o design é ótimo
      A implementação tem pontos fracos, e provavelmente não há patrocínio corporativo que explique por que pouca gente o conhece
      Diferentemente de outras distribuições Linux imutáveis, ele é sólido e simples

  • Uso o Fedora Sericea desde que saiu. Basicamente é o Fedora Silverblue, mas usa Sway-wm em vez do Gnome-wm
    Na prática, é bem utilizável, e também não é preciso reiniciar toda vez que se roda o comando rpm-ostree install. O rpm-ostree live-apply resolve isso com um overlay baseado em systemd

    • Tenho usado o Fedora Workstation nas últimas 2 semanas e, como alguém que voltou a usar Linux depois de 20 anos, posso dizer que a experiência melhorou enormemente
      Ainda não precisei reiniciar no Windows. Se isso continuar assim pelos próximos 6 meses, vou migrar totalmente para Linux e apagar a partição do Windows
    • Ainda assim, para aplicar de fato um kernel novo, não é preciso reiniciar? Ou fico curioso se o kernel é trocado por algo como kexec

  • Sobre a frase “imutabilidade é uma mentira, e muitas partes do sistema são mutáveis. Só não sei como descrever essa família de outra forma; algo transacional?”, no caso do Nix parece que o foco é mais em reprodutibilidade
    A ideia parece ser que, se você colocar o arquivo de configuração do Nix em outro computador, deve obter o mesmo sistema, exceto talvez por /home
    As outras parecem mais próximas de oferecer, com outra implementação, recursos de snapshot e rollback que ferramentas existentes já forneciam

    • “Imutável” é uma palavra estranha para aplicar aqui
      Se significa que você não faz upgrades do sistema em um sistema vivo, que mudanças de pacotes são aplicadas na próxima inicialização e que é possível reverter mudanças, isso se parece mais com transações atômicas, como em bancos de dados. Só que ter que desligar o sistema para fazer o commit é um pouco exagerado
      A Microsoft colocou transações atômicas no sistema de arquivos alguns anos atrás, mas transações de sistema de arquivos não foram muito usadas
      Seria bom se o sistema de instalação pudesse fazer commit de todas as mudanças de uma vez e, se algo desse errado durante a instalação, pudesse voltar ao estado anterior sem commitar nada. Em tese, isso seria possível com um sistema de arquivos transacional, mas, na prática, acho que há estado demais envolvido que não pertence ao sistema de arquivos

  • No lado de servidores, existe o Bottlerocket OS da Amazon
    A ideia é usar partições A/B para upgrades e rodar tudo que não faz parte do sistema básico em contêineres
    Na inicialização, usam-se boot containers para configurações personalizadas, e host-containers para serviços de longa duração, ou DaemonSets no Kubernetes
    https://github.com/bottlerocket-os/bottlerocket