AlpineBSD
Un nuevo proyecto llamado AlpineBSD pretende combinar el kernel de NetBSD con un userland al estilo de Alpine Linux, aplicando además una política estricta de “la menor cantidad posible de código generado por IA”. Los comentaristas debaten si estos ecosistemas de software libres de IA son salvaguardas principistas frente a riesgos legales, éticos y de calidad, o bien un tribalismo poco práctico que aislará a los mantenedores de herramientas útiles y actualizaciones upstream. El hilo también explora las limitaciones reales de NetBSD en hardware y userland, la fragmentación de las comunidades de código abierto por el uso de IA y cómo las futuras cuestiones de licencias y datos de entrenamiento podrían afectar tanto al software propietario como al libre.
Alcance y objetivos del proyecto
- AlpineBSD combina el kernel de NetBSD con un userland inspirado en Alpine y s6 como init (con planes para OpenRC).
- El objetivo declarado es minimizar el código generado por IA (“contaminado”) en los repositorios base y principales, fijando algunas herramientas núcleo (por ejemplo, gcc, binutils, gdb, perl) en las últimas versiones conocidas no LLM.
- Varios comentaristas consideran que la declaración de misión no está clara: ¿está orientado a hardware nativo frente a contenedores, y por qué usar esto en lugar de NetBSD puro? Otros lo ven principalmente como un intento de construir una comunidad afín.
Reacciones a la política libre de IA
- Los partidarios acogen con agrado un espacio “libre de LLM”, lo comparan con una abstención tecnológica de estilo Amish y sostienen que es una forma válida de reducir daños frente a PRs basura de LLM, la pérdida de habilidades, el impacto ambiental y la ambigüedad en torno a los derechos de autor.
- Los críticos califican la postura de tribal o “retrógrada”, argumentando que:
- Los LLM ya son útiles para investigación, prototipado y detección de errores.
- Prohibir cualquier código contaminado obligará a un mantenimiento intenso (toolchains fijadas, menos actualizaciones upstream) y quizá sea insostenible a medida que se generaliza el uso de IA.
- Algunos distinguen entre:
- Rechazar contribuciones generadas por LLM en el propio proyecto (considerado razonable), frente a
- Negarse a consumir cualquier software que contenga alguna salida de LLM (visto por algunos como un exceso ideológico).
Licencias e incertidumbre legal
- Una preocupación recurrente es que los LLM entrenados con código GPL u otro código no permisivo podrían producir resultados que hereden esas licencias, poniendo en riesgo a los proyectos que ingieren ese código.
- Las directrices existentes de NetBSD, que tratan la salida de LLM como “contaminada”, se citan como precedente de políticas cautelosas.
- Otros sostienen que la infracción es difícil de probar, que las demandas son raras y que los regímenes legales pueden adaptarse para normalizar el entrenamiento y uso de IA.
NetBSD frente a Linux y elecciones de userland
- Varios comentarios debaten el soporte de hardware “irregular” de NetBSD: a menudo arranca en una gran variedad de equipos, pero puede carecer de Wi‑Fi, gráficos, gestión de energía y periféricos de portátiles robustos en comparación con Linux.
- Algunos elogian el userland pequeño y simple de Alpine y lo ven como más accesible que el userland predeterminado de NetBSD y el flujo de trabajo de pkgsrc, que varios describen como difícil de instalar, configurar y actualizar.
Viabilidad e impacto en el ecosistema
- Muchos predicen una longevidad limitada para un giro BSD de nicho y anti‑IA de este tipo, señalando híbridos previos de Linux/BSD que desaparecieron.
- Otros ven valor en contar con bases de código “prístinas” escritas por humanos como referencia a largo plazo para entrenamiento y comparación, en medio del crecimiento del código generado por IA y la creciente fragmentación del FOSS en “campos” según la postura frente a la IA.