Servidor de build do F-Droid não consegue compilar apps Android mais recentes devido a CPU antiga

• O servidor de build do F-Droid está em uma situação em que não consegue compilar apps Android mais recentes por causa de uma CPU antiga
• Não há suporte a conjuntos avançados de instruções exigidos por apps móveis modernos, como ARM e x86-64
• É necessário atualizar e substituir os servidores, mas há limitações de custo e infraestrutura
• Desenvolvedores expressam preocupação com a sustentabilidade do F-Droid e sua atualização técnica
• Como alternativa, estão em discussão builds baseadas em nuvem e doações de recursos de servidor pela comunidade

---

Visão geral

• O F-Droid é uma loja não oficial de apps Android de código aberto, com uma estrutura em que os apps são distribuídos após a compilação direta do código-fonte
• Recentemente, os servidores de build deixaram de conseguir oferecer a compilação de alguns apps porque não suportam os conjuntos de instruções de CPU exigidos por apps Android mais recentes

Limitações técnicas dos servidores de build

• A CPU antiga não consegue suportar as novas instruções ARM e x86-64 necessárias para compilar os apps
• Por causa dessa limitação, surgiu o problema de não ser possível fornecer arquivos compilados de apps modernos com otimização de desempenho ou que usam bibliotecas mais recentes
• Linguagens modernas como Python e Kotlin, além de ferramentas de build atuais como o Gradle, também costumam exigir ambientes de CPU mais recentes

Preocupações e discussões na comunidade

• Desenvolvedores e usuários manifestam preocupação com a queda contínua na qualidade dos apps no F-Droid e com os relatos de falhas de build
• A atualização da infraestrutura é necessária, mas ganham destaque as limitações financeiras e a falta de pessoal para administrar os servidores

Busca por alternativas e soluções

• Estão sendo discutidas várias opções, como operar os servidores de build em ambiente de nuvem ou promover doações comunitárias de recursos de servidor
• A equipe do F-Droid afirmou que pretende resolver o problema por meio de apoio externo e aquisição de novo hardware

Conclusão

• O valor do F-Droid e sua importância para o apoio ao ecossistema de código aberto continuam altos
• Ainda assim, esforços de inovação de infraestrutura e manutenção compatíveis com as tendências dos apps modernos são indispensáveis

[GN⁺]

Opiniões do Hacker News

• Isso significa que os servidores deles são realmente muito antigos, a ponto de não suportarem x86-64-v2; dá até para imaginar servidores da época do Intel Core 2 Duo
  Vale conferir este texto que resume o nível de microarquitetura x86-64-v2 no Red Hat Enterprise Linux 9
  Se trocassem por uma CPU de consumidor da linha Epyc, o desempenho do servidor provavelmente ficaria muito mais rápido
  Na verdade eu ia sugerir uma doação, mas vi que eles ainda tinham $80,000
  Considerando que o orçamento anual é de $17,000, até comprar um servidor matx Epyc de consumidor com Zen4 ou Zen5 por 2 a 3 mil dólares ainda caberia no orçamento
  Se realmente houver vários servidores envelhecidos, um único servidor Zen5 poderia substituir vários deles, economizando muito em energia e espaço
  Veja também a situação orçamentária do F-Droid
  Parece que as doações via Librapay ainda não estão incluídas
  Link sobre doações via Librapay

  • Não significa necessariamente que os servidores sejam antigos; na nossa experiência com a plataforma de virtualização, depois de atualizar a VM de um fornecedor externo, ela passou a expor suporte a x86_64v2 + AES no CPU, mas alguns serviços ainda não rodavam
    O requisito mínimo era "Pentium e Celeron", então achamos que seria suficiente
    Só que, na prática, um dos serviços usava instruções suportadas apenas em CPUs v3 ou v4 e parou de funcionar
    Quando mudamos a configuração de CPU exposta, voltou a funcionar normalmente
    Então pode ser que o próprio servidor tenha desempenho suficiente, mas haja erro de configuração, ou que o binário exija mais do que declara, ou algum outro problema
  • Na prática, 2 a 3 mil dólares mal pagam o preço de uma CPU Threadripper básica sem mais nada; com esse valor não dá para comprar um servidor Epyc completo
  • Talvez os servidores estejam inicializando com Coreboot ou Libreboot
  • Também fico em dúvida se o Linux ainda dá suporte oficial a hardware tão antigo assim neste ponto
    A instrução cmpxchg16b nem é tão nova, e hoje já é vista como requisito obrigatório
  • Mesmo que pareça haver dinheiro sobrando, eu ainda recomendaria doar
    £80,000 é muito pouco perto do tempo e do esforço que voluntários gastam para manter esses sistemas
    Já ouvi dizer que a infraestrutura precisa ser modernizada, mas isso exige investimentos grandes
    Se houvesse mais folga no caixa, provavelmente eles poderiam investir com mais confiança
    Há muitos outros desafios além de atualizar os servidores

• A situação atual é bem preocupante
  Acho isso ainda mais importante porque o FDroid é atualmente a maior loja de apps Android fora do Google
  Fico curioso se existe algum plano para resolver isso, quando exatamente o FDroid pretende atualizar os servidores, ou se existe alguma chance de o Google voltar atrás nessa exigência (o que me parece improvável)

  • Considerando que o FDroid é um projeto comunitário operado por voluntários, entendo a preocupação, mas especialmente agora que países da UE estão migrando para software de código aberto, eu gostaria de ver apoio com financiamento público para projetos como o F-Droid
  • Se o f-droid é importante, então também faz sentido doar diretamente para a compra de servidores de build mais modernos
  • Sobre a chance de o Google retirar essa exigência, houve um problema parecido em 2021, quando o Gradle Plugin 4.1.0 passou a exigir instruções SSSE3, causando esse tipo de problema
    Isso foi corrigido no Gradle Plugin 4.2.0-rc01 / Gradle 7.0.0 alpha 9
    O registro do ticket ainda existe
  • Tenho dúvidas de que o FDroid seja mesmo a maior loja Android fora do Google
    Pessoalmente, eu diria que não entra nem no top 10
  • Ao ouvir a explicação de que "as ferramentas de build do Google não são compiladas a partir do código-fonte, mas distribuídas como binários já otimizados", não concordo com a conclusão de que a solução certa seja atualizar os servidores

• Fico pensando por que não recompilam o aapt2 para o alvo
  O código-fonte está disponível
  Local do código-fonte do aapt2

  • Eu perguntaria se você já tentou compilar a AOSP de verdade
    Há uma quantidade enorme de binários, e quando tentei recompilar alguns deles a partir do código-fonte, o sistema de build estava tão quebrado que desisti na hora
  • Usar emulação de CPU com QEMU no Docker é muito mais fácil de manter do que recompilar o aapt2 manualmente toda vez
    Assim dá para acompanhar atualizações de binários automaticamente, sem ter que remendar cada novo binário que surgir

• Compartilho o artigo da Wikipédia sobre Streaming SIMD Extensions (SSSE3)
  Até meu desktop antigo suportava essa instrução, e eu o usei por quase 10 anos
  Mesmo assim, surpreende que nem sequer tenham fornecido um caminho alternativo sem assembly no código-fonte

  • Sobre a dúvida de "como assim não existe nem caminho alternativo sem assembly", imagino que o problema não seja código assembly escrito à mão
    O mais provável é que tenha sido compilado com alvo x86_64-v2
    O RHEL 9 também foi compilado assim, e no RHEL 10 o alvo sobe para x86_64-v3, com suporte a AVX
  • Olhando o issue, parece que o builder usa algo da linha Opteron G3 (K10)
    Link da Wikipédia sobre AMD 10h
  • A falta de um caminho alternativo existe porque faltam máquinas para teste
    Na prática, não há hardware disponível para testar isso, só equipamentos antigos e lentos
  • Se alguém doar um desktop antigo, o FDroid provavelmente vai gostar

• Não entendo completamente
  Como gradle e aapt2 são open source, seria mais previsível compilar tudo diretamente e montar a toolchain, como fazem o buildroot ou o openwrt
  O f-droid também poderia construir a toolchain inteira a partir do código-fonte, evitando o uso de binários gradle ou aapt2 com instruções não suportadas

  • Na prática, eles ainda são obrigados a usar os binários de SDK fornecidos pelo Google
  • Acho essa abordagem razoável, mas o gradle por conta própria baixa dependências como bibliotecas Java pré-compiladas
    Algumas delas incluem binários nativos, e não existe metadado sobre como cada biblioteca foi compilada, como acontece no buildroot ou em distribuições Linux
    Além disso, cada biblioteca no ecossistema gradle tem um processo de build diferente (sem padronização), então reconstruir tudo do zero a partir do código-fonte é um trabalho bem chato e complicado

• Também há quem diga que o Google já corrigiu esse problema no upstream
  Veja este link do issue
  Não dá para ter certeza de quão rápido isso será resolvido, mas a thread passa alguma tranquilidade, mesmo sem uma prova direta de que já tenha sido corrigido

  • Na verdade isso ainda não foi corrigido
    Na thread do link acima, confundiram a correção de um erro de digitação ("mas fixed"→"was fixed") com a resolução deste issue
    O que foi resolvido foi um problema semelhante de alguns anos atrás
    Veja o Google Issue Tracker
  • Até agora esse problema fundamental ainda é pouco conhecido entre os desenvolvedores

• Pensando que sse4.1 foi introduzido em 2011, é estranho que servidores tão antigos ainda estejam em operação
  Com CPUs modernas, o mesmo trabalho poderia ser feito usando só uma fração da energia, então economicamente também não faz muito sentido continuar com hardware velho
  Queria saber se alguém conhece a quantidade ou as especificações desses servidores de build

  • Sobre a ideia de que "com CPUs modernas dá para fazer o mesmo gastando muito menos eletricidade, então é preciso atualizar logo", um CPU de 500W rodando a plena carga o ano inteiro, em 8,760 horas anuais, ainda custaria só $550 em eletricidade
    Mesmo reduzindo isso pela metade, ainda seria apenas 10% do preço de um computador novo, então o retorno levaria 10 anos
    Também há a diferença entre atualização como gasto de capital e conta de luz como despesa operacional
    Fonte sobre preço da eletricidade nos EUA
  • O sse4.1 foi introduzido pela primeira vez no Intel Penryn em novembro de 2007, e a AMD só passou a suportá-lo com o Bulldozer (meados de 2011)
    O Bulldozer trouxe várias instruções novas como AVX e FMA, mas em muitos casos os Opteron antigos ainda eram mais rápidos na prática, então havia pouco incentivo para upgrade até a chegada do Epyc (meados de 2017)
    O motivo de vários pacotes passarem a exigir sse4.1 ou mais é que, em CPUs antigas, o overhead de coisas como desvios condicionais em processamento SIMD era alto demais
  • A resposta real talvez seja "porque dá para usar placas AMD dual-socket com open firmware e sem ME/PSP (como a KGPE-D16)"
  • Não conheço tanto o lado de servidores, mas hardware antigo ainda aparece bastante em desktops
    PCs antigos dos anos 2000 davam conta de tarefas normais como navegar na web, mas com o tempo os programas começaram a exigir instruções novas e foram perdendo utilidade
    Até o Firefox passou a exigir conjuntos de instruções mais novos, e no fim tive que descartar um desktop que ainda funcionava perfeitamente
  • Acho que o motivo de usarem CPUs antigas pode ser firmware livre como Canoeboot ou GNU Boot
    Mas a placa KGPE-D16 aceita CPUs com suporte a SSE4.2 também, então não sei ao certo qual seria o motivo

• Falando do novo binário aapt2 do Google (AGP 8.12.0), o F-Droid é um projeto que se preocupa muito com proteger e isolar o ambiente de build, então é surpreendente que usem binários do upstream em vez de compilar tudo a partir do código-fonte

  • Sobre isso, até bem recentemente ainda não existiam builds de software livre do Android SDK atualizadas
    Para criar apps Android, na prática você acaba dependendo dos binários não livres do Google
    Veja este post do fórum relacionado

• Lista de links de referência
  F-Droid admin issue
  Issue do app Catima
  Issue do MBCompass

  • Lendo a thread do Catima, fica uma impressão muito forte de que é extremamente difícil trabalhar com a comunidade do FDroid
    Um membro disse o seguinte: "Como sempre acontece com o F-Droid, nossas vozes são sempre ignoradas. Se existisse esperança de discutir soluções e melhorar o F-Droid, eu não teria investido tanto tempo e energia para no fim sair frustrado"

• A opinião é que os servidores do F-Droid estão realmente muito ultrapassados
  Mesmo emulando x86_64 em uma arquitetura totalmente diferente já daria para ter ganho de desempenho
  Nem seria preciso entrar na lógica de OSS para defender isso
  Se não houver preocupação com firmware fechado, existem várias opções de servidores x86 mais baratas e modernas

  • Quando alguém diz que "o servidor é realmente antigo", eu sempre acabo esperando uma piada
    Por influência da cultura pop, vem à cabeça algo como "o servidor é tão velho que foi colega de jardim de infância do Benjamin Franklin"