Flatpak deve passar a depender do systemd

• O Flatpak tem promovido como vantagem o slogan “build de apps para todas as distribuições”, mas há uma chance crescente de que passe a ter dependência de systemd na próxima versão principal
• O Flatpak Next ou Flatpak 2.0 se aproxima de uma reescrita para superar limitações de design com décadas de idade da linha 1.x, e ainda está na fase de planejamento
• O novo serviço systemd-appd ficará com o papel central de armazenar identificadores e permissões dos apps, permitindo que outros componentes consultem essas informações e viabilizando o subsandboxing
• Para distribuições sem systemd, havia espaço para uma implementação de daemon independente como o elogind, mas após a ampliação da controvérsia parece ter diminuído a disposição dos desenvolvedores de acomodar esse cenário
• Se a dependência de systemd se tornar mais rígida, pode ficar difícil usar o Flatpak em distribuições como Void, Guix e Alpine, além de enfraquecer sua neutralidade entre distribuições

---

Possível mudança na neutralidade do Flatpak entre distribuições

• O site do Flatpak destaca como primeira vantagem “Build for every distro: create one app and distribute it to the entire Linux desktop market.”, e a lista de distribuições suportadas inclui Void Linux, Guix e Alpine, que usam sistemas de init diferentes do systemd
• Atualmente, o Flatpak não exige que o usuário se preocupe com qual sistema de init está usando, mas há uma possibilidade crescente de que a próxima versão principal passe a ter dependência de systemd
• Se essa mudança for adotada de fato, a questão central será se distribuições que não usam systemd poderão continuar oferecendo o Flatpak

Flatpak Next e a direção do redesenho

• Arian Vovk e Sebastian Wick fizeram uma apresentação no Linux App Summit sobre o futuro do Flatpak
• A versão atual do Flatpak continuará sendo aprimorada, mas está cada vez mais difícil contornar as limitações de um design com décadas de idade
• O trabalho chamado de Flatpak Next ou Flatpak 2.0 é, na prática, próximo de uma reescrita que incorpora a experiência acumulada desde o Flatpak 1.x
• O novo desenho está sendo planejado para aproveitar tecnologias e ideias modernas que se consolidaram após o projeto inicial do Flatpak
• O conteúdo da apresentação ainda está na fase de planejamento, e como nenhuma linha de código foi escrita até agora, o resultado pode mudar bastante ao longo dos próximos anos de desenvolvimento

systemd-appd e a migração do gerenciamento de permissões

• A mudança central na direção de desenvolvimento do Flatpak é mover o gerenciamento de permissões do interior do Flatpak para uma camada de serviço
• O novo serviço systemd-appd atribuirá identificadores aos aplicativos, armazenará permissões e permitirá que outros componentes do sistema consultem esses dados
• Essa estrutura viabiliza vários recursos, e subsandboxing é apontado como um dos mais importantes
• O plano atual é introduzir esse recurso na versão atual do Flatpak, e como resultado o Flatpak passaria a ter dependência de systemd

Espaço para distribuições sem systemd

• Segundo a explicação de Vovk, havia a intenção de ser “muito atencioso” com distribuições e usuários que não usam systemd
• Um modelo previsível seria semelhante ao caso em que o systemd-logind foi separado no daemon independente elogind, permitindo que distribuições com outros sistemas de init também usem ambientes desktop que dependem de systemd-logind
• Os desenvolvedores do Flatpak também pareciam tentar deixar o máximo possível de espaço realista para uma implementação independente semelhante do systemd-appd
• Se essa abordagem tivesse sido mantida, o Flatpak poderia continuar sendo oferecido em distribuições que não usam systemd

Expansão da controvérsia e mudança na reação dos desenvolvedores

• Usuários de distribuições como Void e Alpine levantaram a preocupação de que, se o Flatpak passar a depender fortemente de systemd, ele talvez deixe de funcionar em seus sistemas
• Perguntas foram direcionadas a uma pessoa que não estava tecnicamente envolvida no desenvolvimento do Flatpak, e suas respostas foram em alguns casos pouco úteis, ofensivas e provocativas
• Como muita gente passou a achar por engano que essa pessoa participava do desenvolvimento do Flatpak, perguntas sérias e amigáveis se misturaram com reações agressivas de viés anti-systemd, agravando a situação
• Como resultado, os desenvolvedores do Flatpak passaram a demonstrar em respostas que não querem gastar tempo acomodando distribuições e usuários que não usam systemd
• Se essa tendência continuar, a dependência de systemd pode se tornar mais rígida, e uma implementação de daemon independente que replique os recursos do systemd-appd pode ficar muito mais difícil do que se esperava inicialmente

Resultados esperados e significado

• Na situação atual, é alta a chance de que o Flatpak passe a ter dependência de systemd nos próximos anos
• Também existe a possibilidade de que desapareça a preocupação em facilitar a criação de um daemon independente que substitua os recursos do systemd-appd em distribuições sem systemd
• Nesse caso, o Flatpak deixaria de poder defender com facilidade sua neutralidade entre distribuições e a promessa de distribuir um único app para todas elas
• Como o Flatpak é uma ferramenta com demanda real independentemente do sistema de init usado pelo usuário, essa mudança terá impacto direto no alcance da distribuição de aplicativos para desktop Linux

[GN⁺]

Opiniões no Lobste.rs

• Não entendo por que odeiam tanto o systemd. Pessoalmente, acho que ele oferece recursos úteis com uma API fácil de lidar e um gerenciamento razoável de dependências e conflitos
  Quem não gosta do systemd muitas vezes só apresenta motivos vagos como “não é Unix-like”, “é centralizador” ou “o formato de arquivo do systemd-journald não é texto puro”
  Se for para se opor, queria ver razões concretas, soluções e por que outros sistemas de init seriam melhores. Aí dá para explicar por que scripts rc são hacks terrivelmente bagunçados

  • Grande parte da discussão no Mastodon linkado, no fundo, parece menos anti-systemd e mais anti-centralização. Se o Flatpak passar a depender do systemd, famílias Linux que usam outros sistemas de init perderão acesso ao flatpak
    A filosofia do Linux, pelo menos para mim, sempre foi fundamentalmente sobre escolha, e se o Flatpak exigir um init específico, isso reduz as opções do usuário na hora de montar o sistema para obter o resultado desejado
  • Eu uso systemd sem problemas, mas no caso do Flatpak entendo a reação. O Flatpak é, em essência, algo mais próximo de “fazer funcionar em qualquer distribuição Linux”, então depender do systemd reduz um pouco essa utilidade
  • Minha insatisfação com o systemd, sem exageros, é mais ou menos esta: a implementação do journald não é grande coisa, embora a ideia em si seja boa, e a fila de jobs, que é a abstração real usada pelo systemd para gerenciar units, tem casos de borda esquisitos que não são documentados ou são difíceis de encontrar
    Também deveria ser mais fácil colocá-lo dentro de imagens de contêiner, e o systemd do usuário deveria ter acesso de API de leitura à instância do sistema para ao menos poder agendar units com coisas como After e Requires
    Ainda assim, acho que foi a melhor coisa que aconteceu com o Linux desde a remoção do HAL, e já até apertei a mão do Lennart para agradecer pelo projeto
  • Projetos como o Chimera, que de fato implementam uma pilha alternativa confiável, são gentis e humildes sem espalhar FUD. Já a massa de indignação online explicitamente não tem solução, nem vai ter
    O que esses “opositores” defendem na prática está mais para dizer que a própria solução não deveria existir. Agem como uma HOA do Linux e me parecem mais uma política reacionária que atrapalha o avanço de sistemas sólidos, utilizáveis e competitivos capazes de deslocar sistemas operacionais proprietários
  • Não odeio o systemd se ele for usado só em sistemas cuja função é servir páginas web ou exibi-las em um navegador GUI. Também não tenho problema em usar units do systemd diretamente para deploy em VPS; se fosse SysV init ou upstart, também não me incomodaria muito
    Mas no notebook eu quero outra coisa. Tenho ideias sobre como meu ambiente pessoal deve funcionar, quero algumas conveniências que o usuário comum de Linux talvez não queira e não quero que coisas aconteçam sem eu pedir explicitamente. Odeio muito mais o esforço para “fazer algo parar de acontecer” do que o esforço para “fazer funcionar”
    O principal motivo de eu ter deixado o NixOS por causa do systemd foi o escopo sempre crescente e os padrões fortemente opinativos. À medida que gerenciamento de energia e login foram integrados, eu precisava corrigir repetidamente comportamentos como suspender obrigatoriamente ao fechar a tampa; mudanças no alcance permitido de linger quebraram nohup e screen, exigidos pelo POSIX; e um controle mais rígido de VT me forçou a redesenhar “fazer login uma vez e rodar várias instâncias do Xorg” ou “capturar VT” do jeito do systemd
    No fim, concluí que um init mínimo como sinit, sem supervisão de serviços, era melhor, e passei a escrever meus próprios scripts de boot em shell, implementando algumas funções do sistema em shell e outras em Common Lisp. Em notebook, algo como PostgreSQL, uma vez iniciado, continua rodando; se parar, eu percebo; se reiniciar resolver, é simples; e se não resolver, um supervisor de serviços também não vai ajudar
    Exemplos que quebraram minha confiança incluem esperar vários minutos sem saída do journald para mostrar logs em um HDD com cache frio, ter vivenciado pessoalmente https://github.com/systemd/systemd/issues/2913 e o fato de não terem hesitado em quebrar nohup
    No desenvolvimento também perdi confiança por atitudes que, em https://github.com/systemd/systemd/issues/437, soavam como “fornecemos bons padrões, mas se forem ruins a distro que corrija”, além da relutância em prometer APIs estáveis em http://lists.freedesktop.org/archives/systemd-devel/…
    Dito isso, essas reclamações já são antigas. Depois de ver o systemd resolver certos problemas enquanto criava outros, e perceber que nenhum deles era problema meu para começo de conversa, migrei no notebook para scripts de boot em shell, e hoje o custo de manter tudo como está é baixo demais para eu querer testar systemd de novo. Em VPS, uso systemd dentro do escopo familiar do Debian

• É frustrante que isso tenha começado por alguém que não é desenvolvedor do Flatpak espalhando desinformação, provocando reações emocionais, e que, conforme a thread original avançava, surgissem formulações ainda mais fortes, levando pessoas a atacar a reputação do projeto Flatpak e de seus desenvolvedores
  Como resultado, também não surpreende que os desenvolvedores reais do Flatpak tenham sido afetados emocionalmente e passado a querer se distanciar da multidão enfurecida
  Queria que todo mundo se acalmasse e não ampliasse mais essa história. Se houver dúvidas ou preocupações, conversem com os mantenedores de fato, mostrem apoio à busca de um meio-termo e deixem claro que isso é um caso isolado de certas pessoas, não algo que represente a comunidade inteira
  Assim como a ideia de depender do systemd não passava de uma ideia, também acho que ainda não está fechada a possibilidade de os mantenedores reconsiderarem o suporte a projetos mais diversos

• Espero que as pessoas se deem bem o suficiente para continuar oferecendo suporte a sistemas que não rodam sobre systemd. O Flatpak e outras abordagens baseadas em contêineres ajudam usuários a executar pacotes que não são fáceis de compilar para a plataforma alvo, e seria bom poder rodar Flatpak nesses sistemas quando algum software específico for necessário
  Contêineres cumprem papel parecido, mas fazer algo como x11docker funcionar direito em configurações suficientemente incomuns pode ser irritantemente complicado

  • Uso o Void com satisfação há mais de 10 anos. Nem lembro quando foi a última vez que me preocupei com sistema de init ou integração com systemd. Sou grato por todo o trabalho investido no Void

• Uso Void no notebook; é eficiente para trabalhar e a documentação é bem boa. Agradeço por todo o trabalho que os desenvolvedores têm feito e espero que essa mudança no Flatpak não vire um peso grande demais

• “Este é o Linux moderno, e só existe systemd.”
  Isso faz lembrar com clareza que a comunidade Linux se parece mais com a WeWork do que com uma comunidade. Enquanto todo mundo ao redor recebe salário dependendo da existência da Red Hat, alguém está hackeando o GNU readline de graça

  • Não dá para dizer que o texto esteja errado nessa parte: a passagem sobre “atrair fanáticos anti-systemd e teóricos da conspiração da Red Hat (e tipos ainda piores)”

• Neste estágio, parece cedo demais para afirmar categoricamente que “vai passar a depender”, e isso soa bastante especulativo

• É interessante como o título é muito mais categórico do que o próprio texto. Muitos comentários claramente estão reagindo só ao título e, felizmente, não todos, mas isso não é novidade na internet
  Ultimamente até no lobste.rs tenho visto com frequência gente reagindo apenas ao título ou a uma frase dentro de um comentário longo, e isso me preocupa. Em geral, quase não deixam espaço para outras possibilidades além da primeira interpretação que lhes vem à cabeça, muitas vezes agressiva
  Lendo o texto, parece que algo parecido também aconteceu no debate sobre o Flatpak 2.0. Eles aparentemente tentaram deixar espaço para outros sistemas de init, mas o discurso ao redor ficou hostil tão rápido que isso acabou sendo praticamente abandonado

• Para quem usa um sistema de init alternativo, isso é realmente frustrante. Tenho um notebook rodando Alpine Linux e vinha usando Flatpak para executar software que só funciona com glibc. Essa mudança vai me fazer abandonar esse ambiente
  Eu não odeio systemd. Todos os meus sistemas Gentoo usam systemd. O que não me agrada é a forma como o systemd faz com que software livre e de código aberto dependa cada vez mais do GNU/Linux

• Isso claramente é uma coisa boa
  O systemd é composto de daemons com APIs estáveis e bem definidas, então qualquer parte do systemd da qual o Flatpak passe a depender poderia, com algum esforço, ser reimplementada de forma limpa por alguém
  É o melhor resultado possível. A fragmentação diminui, e as pessoas com requisitos fora do comum ganham um alvo estável para reimplementação

  • Comecei a ler achando que era sátira, mas não era
    As APIs do systemd costumam ser definidas de forma vaga nas páginas de manual, e como o lado do systemd não espera outras implementações, elas também não são estáveis nem versionadas nos dois sentidos
    No caso da API de socket de notificação, a estabilidade existe mais no sentido oposto. A adição de suporte a vsock praticamente quebrou daemons implementados sem depender de libsystemd. Essa quebra não ficou muito conhecida porque o vsock era usado principalmente para comunicação entre systemd através de fronteiras de virtualização. Se fosse bem projetado, isso teria sido feito como uma extensão usada apenas nessa fronteira
    Fala-se em “daemons”, mas na prática é basicamente logind e systemd, e são esses dois que expõem quase toda a superfície de API, então a componibilidade é limitada. Fazem isso por meio de algumas interfaces DBus, agora também varlink, e uma única biblioteca
    Para substituir o systemd, é preciso ou substituir tudo de uma vez e fazer um encaixe difícil para expor o modelo interno como APIs no estilo do systemd, ou primeiro desfazer as escolhas de projeto das APIs do systemd e criar uma camada intermediária com backends plugáveis
    Lido com esse problema há anos. Acho muitos dos princípios de projeto do systemd válidos, mas o desenho atual empurra para a frente uma complexidade de que a maioria das pessoas não precisa. Um projeto mais modular e substituível é possível, e também é relativamente fácil imaginar ou reaproveitar interfaces simples e separáveis
    Mas o problema é o software que escolhe depender das APIs do systemd. Para fazê-lo funcionar com outra coisa, seria preciso upstreamar patches que separem o suporte às funcionalidades amarradas à libsystemd inteira, ou adicionar suporte a novas APIs individuais; a primeira opção nunca deu certo, e a segunda tende a ser rejeitada pelo custo de manutenção de APIs pequenas ou ainda não lançadas
    Ou então dá para implementar só as APIs que o software usa. Por exemplo, usar um serviço DBus login1 que não implementa a maior parte das APIs. Mas aí isso entra em conflito com outras implementações que tentam substituir outras partes da API, e você acaba tendo de implementar três variações: a API originalmente limpa, a API DBus de logind/systemd e a API para varlink
    No longo prazo, a solução pode ser implementar a API completa do systemd ou do logind e, por trás, conectá-la a APIs separadas por meio de um roteador. Só que o projeto atual está carregado de duplicação extrema e especificidades do systemd, então fazer isso direito é muito complexo
    Não sei se era a intenção, mas pelas falas dos desenvolvedores do systemd, no mínimo foi algo com que deliberadamente escolheram não se importar. Criar uma camada intermediária complexa ou fazer um substituto do systemd sem reescrever o próprio systemd é muito difícil, e mesmo quando um aplicativo depende apenas de parte das APIs que poderiam ser oferecidas como componentes isolados, na prática é muito difícil substituir de forma limpa apenas uma parte do systemd
  • Será que essa ideia de que partes do systemd podem ser reimplementadas de forma limpa do zero ainda corresponde à realidade? O texto cita o elogind como exemplo

• Não gosto da forma como a Red Hat acaba tendo controle demais sobre o ecossistema Linux

  • Eu também não, mas hoje em dia não sei bem quanto controle a Red Hat realmente tem sobre o systemd
  • É bem ambíguo. Centralizar controle é ruim, mas pagar pessoas para fazer software livre e de código aberto é bom. E boa parte do controle que eles ganham vem justamente de pagar pessoas para fazer software livre e de código aberto
    Ainda assim, o fato de a Red Hat abraçar software livre ameniza um pouco as preocupações com essa influência. Ao olhar as tecnologias que comprou ao longo dos anos, houve casos em que ela própria criou um upstream livre e de código aberto mesmo para coisas que antes não tinham upstream. Dogtag PKI e 389 Directory Server vêm especialmente à mente
    No geral, eu diria que isso não foi ruim para o ecossistema; na maioria das vezes ajudou mais do que atrapalhou

• Não tenho nada em jogo diretamente nessa disputa, mas aqui não há nada que alivie a ansiedade sobre a complexidade e abstração desnecessárias que continuam aumentando nos sistemas Linux
  O Linux está rapidamente virando o Java dos sistemas operacionais. É realmente triste