El servidor de compilación de F-Droid no puede compilar apps Android modernas debido a una CPU antigua

 (news.ycombinator.com)
1 puntos por GN⁺ 2025-08-14 | 1 comentarios | Compartir por WhatsApp
  • El servidor de compilación de F-Droid está teniendo problemas para compilar apps Android modernas debido a una CPU antigua
  • No puede soportar los conjuntos de instrucciones avanzadas requeridos por apps móviles modernas en ARM, x86-64 y otras arquitecturas
  • Se necesita una actualización y reemplazo de los servidores, pero existen limitaciones de costo e infraestructura
  • Los desarrolladores han expresado preocupación por la sostenibilidad de F-Droid y su vigencia técnica
  • Como alternativas, se están discutiendo la compilación basada en la nube y la donación de recursos de servidor

Resumen

  • F-Droid es una tienda no oficial de apps Android de código abierto que distribuye aplicaciones compilando directamente su código fuente
  • Recientemente, sus servidores de compilación dejaron de poder ofrecer compilaciones de algunas apps porque no soportan los conjuntos de instrucciones de CPU requeridos por las apps Android modernas

Limitaciones técnicas de los servidores de compilación

  • La CPU antigua no soporta las nuevas instrucciones ARM y x86-64 necesarias para compilar apps
  • Debido a esta limitación, surgió el problema de no poder ofrecer archivos compilados de apps modernas optimizadas en rendimiento o de apps que usan bibliotecas recientes
  • Lenguajes modernos como Python y Kotlin, así como herramientas de compilación modernas como Gradle, también suelen requerir entornos de CPU más actuales

Preocupaciones y debate dentro de la comunidad

  • Desarrolladores y usuarios han expresado preocupación por el deterioro continuo de la calidad de las apps en F-Droid y por los reportes de fallas de compilación
  • Aunque es necesario actualizar la infraestructura, se han hecho evidentes las limitaciones financieras y la falta de personal para administrar los servidores

Búsqueda de alternativas y soluciones

  • Se están discutiendo diversas opciones, como operar los servidores de compilación en un entorno en la nube o impulsar donaciones de recursos de servidor por parte de la comunidad
  • El equipo de F-Droid expresó su intención de resolver el problema asegurando apoyo externo y nuevo hardware

Conclusión

  • El valor de F-Droid y su papel en el apoyo al ecosistema de código abierto siguen siendo muy altos
  • Sin embargo, son imprescindibles esfuerzos de innovación en infraestructura y mantenimiento acordes con las tendencias de las apps modernas

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-08-14
Opiniones de Hacker News

  • Esto implica que sus servidores realmente son muy viejos, al punto de no soportar x86-64-v2; casi hace pensar en servidores de la era del Intel Core 2 Duo
    Vale la pena revisar este artículo que resume el nivel de microarquitectura x86-64-v2 de Red Hat Enterprise Linux 9
    Si los cambiaran por CPUs de consumo Epyc, parece que el rendimiento del servidor mejoraría muchísimo
    De hecho intenté donar, pero ya les quedaban $80,000
    Considerando que su presupuesto anual es de $17,000, incluso comprando por 2 o 3 mil dólares un servidor Epyc de consumo mATX moderno Zen4 o Zen5 seguirían dentro del presupuesto
    Si de verdad tienen varios servidores muy envejecidos, un solo servidor Zen5 podría reemplazar a varios, además de ahorrar mucho en energía y espacio
    También revisé el estado del presupuesto de F-Droid
    Parece que las donaciones de Librapay todavía no están incluidas
    Enlace de donaciones en Librapay

    • No necesariamente significa que los servidores sean viejos; por nuestra experiencia con la plataforma de virtualización, después de actualizar una VM de un proveedor externo y exponer soporte para x86_64v2 + AES desde el CPU, algunos servicios no arrancaban
      El requisito mínimo decía "Pentium y Celeron", así que pensamos que sería suficiente
      Pero en realidad uno de los servicios usaba instrucciones soportadas solo en CPUs v3 o v4, y dejó de funcionar
      Al cambiar la configuración del CPU expuesto, volvió a correr normalmente
      Así que el servidor como tal sí podría tener rendimiento suficiente, y el problema podría ser una mala configuración, o que el binario requiera especificaciones más altas de las que declara, u otro tipo de problema
    • En realidad, $2~3 mil dólares apenas alcanza para el precio de un CPU Threadripper de gama baja, y con eso no compras un servidor Epyc completo
    • También podría ser que el servidor esté arrancando con Coreboot o Libreboot
    • A estas alturas incluso me pregunto si Linux sigue soportando oficialmente hardware tan viejo
      La instrucción cmpxchg16b no es tan antigua y hoy se considera un requisito obligatorio
    • Aunque quedara poco dinero, igual recomendaría donar
      Comparado con el tiempo y esfuerzo que los voluntarios dedican a mantener el sistema, £80,000 es realmente muy poco dinero
      He escuchado que hace falta modernizar la infraestructura, pero eso requiere una inversión importante
      Si tuvieran más holgura en los fondos, probablemente podrían invertir con más confianza
      Además del upgrade de servidores, hay muchos otros problemas por resolver

  • La situación actual sí me preocupa bastante
    F-Droid es, fuera de Google, la tienda de apps de Android más grande que existe ahora mismo, así que me parece aún más necesaria
    Me pregunto si hay algún plan para resolver esto, cuándo podría F-Droid actualizar sus servidores, o si existe la posibilidad de que Google retire este requisito obligatorio, aunque veo poco probable este último caso

    • Considerando que F-Droid es un proyecto comunitario manejado por voluntarios, entiendo la preocupación, pero me gustaría que proyectos como F-Droid recibieran financiamiento público, sobre todo ahora que países de la UE se están moviendo hacia software de código abierto
    • Si f-droid es importante, entonces también hace falta donar directamente para que puedan comprar servidores de build modernos
    • Sobre la posibilidad de que Google retire el requisito, ya hubo un problema parecido en 2021: en ese momento Gradle Plugin 4.1.0 requería la instrucción SSSE3 y eso causó el incidente
      Ese problema se corrigió en Gradle Plugin 4.2.0-rc01 / Gradle 7.0.0 alpha 9
      Incluso quedó el registro del ticket
    • Tengo mis dudas sobre que F-Droid sea la tienda de Android más grande después de Google
      Personalmente, creo que ni siquiera entraría al top 10
    • Después de escuchar la explicación de que "las herramientas de build de Google no se compilan desde fuente y salen como binarios optimizados por separado", no estoy de acuerdo con concluir que la solución correcta sea actualizar los servidores

  • Me pregunto por qué no vuelven a compilar aapt2 para ajustarlo al objetivo
    Se puede conseguir el código fuente
    Ubicación del código fuente de aapt2

    • Me gustaría preguntar si alguien aquí ha compilado AOSP de verdad
      Está lleno de binarios, y cuando intenté recompilar algunos desde fuente, el sistema de build estaba tan roto que me rendí de inmediato
    • Usar emulación de CPU con QEMU dentro de Docker es mucho más fácil de mantener que recompilar aapt2 manualmente cada vez
      Así pueden absorber automáticamente futuras actualizaciones de binarios sin tener que volver a parchear cada uno

  • Comparto el artículo de Wikipedia sobre Streaming SIMD Extensions (SSSE3)
    Hasta mi viejo desktop soportaba esa instrucción, y lo usé durante casi 10 años
    Aun así, sorprende que ni siquiera hayan dejado una ruta de respaldo en ensamblador en el código fuente

    • Sobre la duda de "por qué no hay una ruta de respaldo ni siquiera en ensamblador", probablemente no sea un problema de código ensamblador escrito a mano
      Lo más probable es que el compilador lo haya compilado con objetivo x86_64-v2
      RHEL 9 también se construyó con esa opción, y en RHEL 10 sube a x86_64-v3, agregando soporte para AVX
    • Revisando el issue, el builder parece ser de la familia Opteron G3 (K10)
      Enlace de Wikipedia sobre AMD 10h
    • El problema de no ofrecer una ruta de respaldo se debe a la falta de hardware de prueba
      En la práctica no tienen hardware donde probar esto, salvo equipos viejos y lentos
    • Si alguien dona un desktop viejo, probablemente a FDroid le encantaría

  • No termino de entenderlo
    Si gradle y aapt2 son open source, compilar directamente el toolchain, como se hace en buildroot u openwrt, daría resultados más predecibles
    Del mismo modo, si f-droid construyera todo el toolchain directamente desde fuente, ya no tendría que usar binarios de gradle o aapt2 con instrucciones no soportadas

    • En la práctica, todavía no queda más opción que usar los binarios del SDK que provee Google
    • Creo que la idea tiene sentido, pero gradle descarga y usa dependencias por su cuenta, como bibliotecas Java precompiladas
      Algunas incluyen binarios nativos, y no existe metadata sobre cómo se construyó cada biblioteca, como sí pasa en buildroot o en una distro Linux
      Además, cada biblioteca del ecosistema de gradle tiene un proceso de build distinto, sin estandarización, así que reconstruir todo directamente desde fuente sería un trabajo bastante engorroso y complicado

  • También se dice que Google ya corrigió este problema en upstream
    Ver este enlace al issue
    No estoy seguro de qué tan rápido se resolverá, pero aunque el hilo no da una prueba directa de que ya esté corregido, de todas formas deja algo más de tranquilidad

    • En realidad todavía no está corregido
      En el hilo enlazado confundieron una corrección de typo ("mas fixed"→"was fixed") con la resolución de este issue
      Lo que se corrigió fue un problema similar de hace algunos años
      Ver el Google Issue Tracker
    • Hasta ahora, este problema de fondo sigue siendo poco conocido entre los desarrolladores

  • Considerando que sse4.1 es una instrucción introducida en 2011, sorprende que todavía haya servidores tan viejos en operación
    Con un CPU moderno podrían hacer lo mismo usando solo una fracción de la energía, así que tampoco se entiende económicamente seguir con hardware tan antiguo
    Me pregunto si alguien sabe cuántos servidores de build tienen o qué especificaciones manejan

    • Sobre la idea de que con CPUs modernos harían lo mismo con una fracción de la electricidad y por eso deberían actualizar cuanto antes: de las 8,760 horas al año, incluso si un CPU de 500W trabajara al 100% todo el año, la electricidad costaría $550
      Aunque lo reduzcas a la mitad, sigue siendo apenas el 10% del precio de una computadora nueva, así que recuperar la inversión tardaría 10 años
      Además, un upgrade es gasto de capital, mientras que la electricidad es gasto operativo
      Fuente sobre el precio de la electricidad en EE. UU.
    • sse4.1 fue introducida por primera vez en Intel Penryn en noviembre de 2007, y AMD no la soportó hasta Bulldozer, a mediados de 2011
      Bulldozer agregó varias instrucciones nuevas, como AVX y FMA, pero muchos Opteron anteriores seguían siendo más rápidos en la práctica, así que antes de Epyc, a mediados de 2017, no había tanto incentivo para actualizar
      Una de las razones por las que muchos paquetes empiezan a exigir sse4.1 o superior es que en CPUs viejos el overhead de cosas como ramas condicionales en procesamiento SIMD paralelo es alto
    • La respuesta real podría ser simplemente: "porque permite usar placas AMD de doble socket con open firmware y sin ME/PSP, como la KGPE-D16"
    • No sé mucho del mundo de servidores, pero sí es común ver hardware viejo en desktops
      Las PCs viejas de los 2000 todavía servían bien para tareas normales como navegar por la web, pero con el tiempo los programas empezaron a requerir nuevas instrucciones y fueron perdiendo utilidad
      Incluso Firefox terminó exigiendo conjuntos de instrucciones más nuevos, y al final tuve que tirar un desktop que por lo demás seguía funcionando perfectamente
    • Creo que usan CPUs viejos por temas de firmware libre, como Canoeboot o GNU Boot
      Pero la placa KGPE-D16 sí puede montar CPUs con soporte para SSE4.2, así que no tengo claro cuál sea la razón exacta

  • Hablando del nuevo binario aapt2 de Google (AGP 8.12.0), F-Droid es un proyecto que pone muchísima atención en proteger y aislar el entorno de build, así que sorprende que aun así usen binarios de upstream en vez de compilar todo desde fuente

    • En relación con eso, hasta hace relativamente poco ni siquiera existía una build de software libre del Android SDK que se mantuviera actualizada
      Para crear apps de Android, básicamente terminas dependiendo de binarios privativos de Google
      Ver este post del foro

  • Resumen de enlaces de referencia
    F-Droid admin issue
    Issue de la app Catima
    Issue de MBCompass

    • Al leer el hilo de Catima, queda una impresión muy fuerte de que es bastante difícil trabajar con la comunidad de FDroid
      Un miembro dijo esto: "Como siempre pasa con F-Droid, nuestras voces siempre son ignoradas. Si hubiera existido la esperanza de que discutir soluciones pudiera mejorar F-Droid, no habría terminado yéndome frustrado después de invertir tanto tiempo y energía"

  • La opinión es que los servidores de F-Droid de verdad están muy obsoletos
    Incluso emular x86_64 sobre una arquitectura completamente distinta podría dar mejor rendimiento
    Ni siquiera hace falta recurrir a una lógica de OSS para defenderlo
    Si no te preocupa el firmware cerrado, hay muchas opciones de servidores x86 más baratos y más modernos

    • Cuando alguien dice "los servidores están realmente obsoletos", casi dan ganas de esperar un chiste
      Por culpa de la cultura popular, uno termina pensando en bromas como "el servidor es tan viejo que fue compañero de kínder de Benjamin Franklin"