Gentoo lanza versión binaria
(gentoo.org)- Gentoo mantiene su carácter de distribución basada en código fuente, pero ahora ofrece descarga oficial e instalación directa de paquetes binarios para hardware lento y mayor facilidad de instalación
- El alcance varía según la arquitectura; amd64 y arm64 pueden recibir más de 20 GB de paquetes y paquetes Gentoo stable actualizados a diario
- Las instalaciones nuevas desde stage incluyen la configuración del repositorio binario, y las instalaciones existentes pueden usarlo agregando un archivo de configuración en
/etc/portage/binrepos.conf/ - Los paquetes oficiales usan el formato GPKG, que admite firmas, y si la verificación falla se rechaza la instalación; sin embargo, en la configuración predeterminada también pueden permitirse XPAK sin firma por compatibilidad
- Si se usan combinaciones de USE flags distintas de los valores predeterminados del perfil, es difícil usar los paquetes binarios tal cual, por lo que habrá que combinarlos con compilación local cuando sea necesario
Gentoo ofrece paquetes binarios oficiales
- Gentoo ofrece la función de paquetes binarios, que Portage soportaba desde hace mucho, mediante descarga oficial e instalación directa
- El objetivo es reducir el tiempo de trabajo en hardware lento y mejorar la comodidad de la instalación y actualización completas
- Sigue siendo una distribución basada en código fuente como antes, y se pueden usar compilaciones desde código fuente junto con paquetes binarios
Alcance por arquitectura
- La mayoría de las arquitecturas se limitan al sistema core y a actualizaciones semanales
- amd64 y arm64 ofrecen un conjunto de paquetes más amplio
- Hay más de 20 GB de paquetes en los mirrors
- Incluye LibreOffice, KDE Plasma, Gnome, Docker, entre otros
- Los paquetes Gentoo stable se actualizan a diario
Cómo configurar según el entorno de instalación
- Para usar paquetes binarios en una instalación existente de Gentoo, hay que crear un archivo de configuración en
/etc/portage/binrepos.conf/- El procedimiento general puede consultarse en Binary package quickstart
- La configuración más detallada está reunida en la binary package guide
- Las instalaciones nuevas basadas en stage ya incluyen
/etc/portage/binrepos.conf/gentoobinhost.conf- Si es necesario, se puede cambiar
src-uripor el URI del directorio correspondiente de un mirror local - Un ejemplo de actualización es
emerge -uDNavg @world
- Si es necesario, se puede cambiar
Criterios de compilación para amd64 y arm64
- Los paquetes binarios bajo
amd64/binpackages/17.1/x86-64se compilan con la siguiente configuraciónCFLAGS="-march=x86-64 -mtune=generic -O2 -pipe"- Funcionan en todas las máquinas amd64 / x86-64
- La configuración de USE flags y las versiones de los paquetes amd64 corresponden a perfiles de paquetes estables
amd64/17.1/nomultilibamd64/17.1/desktop/plasma/systemdamd64/17.1/desktop/gnome/systemd
- Los paquetes bajo
arm64/binpackages/17.0/arm64se compilan con la siguiente configuraciónCFLAGS="-O2 -pipe"- Funcionan en todas las máquinas arm64 / AArch64
- La configuración de USE flags y las versiones de los paquetes arm64 también se ajustan a perfiles de paquetes estables
arm64/17.0arm64/17.0/desktop/plasma/systemdarm64/17.0/desktop/gnome/systemd
- Si se requiere optimización específica por CPU, hay que compilar directamente como antes
Integración con otras arquitecturas y stages
- El hosting de paquetes binarios para otras arquitecturas y ABI está vinculado a las compilaciones stage
- Para casi todos los stages se ofrece hosting de paquetes binarios que incluye solo el contenido y la configuración de ese stage
- Ese alcance incluye compiladores
gccoclangy toda la toolchain de compilación - Por ahora no hay planes de ampliar más este alcance
Firmas y método de verificación
- Los paquetes binarios oficiales están firmados criptográficamente con las mismas claves que los stages
- La información de las claves de firma puede consultarse en Gentoo signatures
- Portage maneja dos formatos de paquetes binarios
- XPAK: formato anterior, no admite firmas
- GPKG: formato nuevo, admite firmas criptográficas
- Todos los paquetes binarios oficiales de Gentoo están en formato GPKG
- En los paquetes GPKG se verifica la firma
- Si la verificación falla, la instalación se rechaza
- En la configuración predeterminada, también pueden instalarse paquetes XPAK sin firma para mantener compatibilidad con paquetes binarios antiguos
- Para exigir firmas verificadas, hay que configurar
FEATURES="binpkg-request-signature"enmake.conf- En ese caso, solo se pueden usar paquetes GPKG
Errores de firma y paquetes propios
- Si aparece un error indicando que no se puede verificar la firma, se puede ejecutar como root Gentoo Trust Tool
getuto- El ejemplo de comando es
getuto - Configura el keyring de Gentoo Release Engineering necesario para Portage
- El ejemplo de comando es
- Si
FEATURES="binpkg-request-signature"está activado enmake.conf,getutose invoca automáticamente antes de descargar paquetes binarios- Es un comportamiento para traer actualizaciones y revocaciones de claves
- Portage puede rechazar paquetes binarios creados por el usuario
- Es un efecto secundario de
FEATURES="binpkg-request-signature" - Para paquetes propios, hay que configurar una clave de firma y hacer que el ancla en
/etc/portage/gnupgconfíe en esa clave
- Es un efecto secundario de
Restricciones de mirrors, perfiles y USE flags
- Si la descarga es lenta, se recomienda usar un mirror local en lugar de University of Oregon
- Basta con modificar el URI en
/etc/portage/binrepos.conf - Gracias a las firmas criptográficas, usar un mirror local sigue siendo seguro
- Basta con modificar el URI en
- Si se usan combinaciones de USE flags distintas de los valores predeterminados del perfil, no se podrán usar esos paquetes binarios
- Portage puede mezclar paquetes binarios y paquetes compilados localmente
- Gentoo no apunta a una instalación completamente basada solo en binarios
- Los paquetes también pueden usarse en sistemas merged-usr
- Si surge un problema, debe reportarse como bug
- No pueden usarse junto con otros perfiles más antiguos o más nuevos
- Por eso la ruta
src-uriincluye una versión de perfil como17.1 - Cuando aparece una nueva versión de perfil, se ofrece un nuevo directorio de paquetes separado
- Por eso la ruta
~amd64 y reporte de problemas
- Todavía no hay planes de ofrecer paquetes binarios
~amd64- Hacerlo requeriría muchas recompilaciones
- Incluso si se ofrecieran, por razones técnicas necesitarían un URI separado
- Si se necesitan paquetes de testing, se recomienda mantener stable tanto como sea posible y agregarlos localmente en
package.accept_keywords- Muchos paquetes binarios podrán seguir usándose
- El resto tendrá que compilarse directamente
- Si hay problemas con Portage o con algún paquete específico, se puede pedir consejo en IRC, foros o listas de correo, o enviar un bug
- El soporte de paquetes binarios se probó durante cierto tiempo, pero a medida que aumente la cantidad de usuarios pueden aparecer casos límite
1 comentarios
Opiniones de Hacker News
Para dejarlo claro desde el principio, soy fan acérrimo de Gentoo.
El atractivo de Gentoo no está en compilar todo desde el código fuente, sino en la excelente documentación y la libertad de instalar lo que uno quiera en casi cualquier hardware, con barreras mínimas.
Si quieres usar Enlightenment + OpenRC + NetworkManager en una laptop de 2008, instalas Gentoo; y si quieres usar ZFS en el sistema de archivos raíz de un refrigerador inteligente, Gentoo también sirve.
Si quieres usar Gnome puro + SystemD en una laptop nueva, también es posible.
La decisión de ofrecer paquetes binarios le da más opciones al usuario, en contraste con otras distribuciones que han ido reduciendo la libertad de elección.
Debian se presenta como un “sistema operativo universal”, pero dejó de dar soporte a x86 de 32 bits, y aunque se pueden instalar sistemas init alternativos, es bastante engorroso.
En cambio, Gentoo permite elegir entre más de 17 tarballs stage 3 y 35 perfiles eselect.
Personalmente disfruto compilar todo desde el código fuente y la flexibilidad que eso da, y en hardware moderno no es nada doloroso.
Si no estás de acuerdo, puedes instalar los nuevos paquetes binarios.
El punto fuerte de Gentoo nunca fue Portage, sino siempre la flexibilidad y la comunidad.
Es más bien que, en una reunión del equipo de releases, se concluyó que en algún momento no especificado del futuro probablemente desaparecerán el instalador y el soporte de kernel para x86 de 32 bits.
Actualmente ambos siguen estando disponibles y totalmente soportados.
En particular, como se puede seguir usando multiarquitectura de 32/64 bits, también es posible ejecutar software x86 de 32 bits.
Todos quisieran soportarlo todo, pero al final, para garantizar seguridad y mantenimiento como distribución, los recursos disponibles son limitados.
Algunas cosas necesariamente hay que dejarlas de lado.
En cualquier distribución Linux puedes instalar lo que quieras, pero el alcance de lo que realmente se puede decir que está soportado siempre queda limitado por la cantidad de mantenedores.
https://buildd.debian.org/status/package.php?p=base-files&su...
Lo sé porque mantengo personalmente la mayoría de las arquitecturas menos conocidas de Debian junto con snapshots de instalación periódicos.
https://cdimage.debian.org/cdimage/ports/snapshots/
Debian también tiene ports de Hurd tanto para i386 como para amd64.
No estaba usando perfiles musl ni clang.
Como esa fue mi primera impresión, no pienso considerarlo a menos que Gentoo o algún fork derivado ofrezca un instalador.
Pronto voy a probar instalar Solus OS / Solus Linux; su gestor de paquetes me dejó una buena primera impresión y afirma ser reproducible, aunque no al estilo de nix o guix.
Para mí, el gran atractivo de Gentoo es Portage.
Ofrece mucho más que un entorno de compilación simple y gestión de dependencias.
Los ebuilds, es decir, los paquetes de Gentoo, cuentan con el apoyo de excelentes herramientas y Eclasses que manejan varias situaciones excepcionales de compilación.
Desarrollar un ebuild se siente como trabajar en un proyecto de software real, y es ideal para quienes quieren experimentar con paquetes que no están en el repositorio oficial.
Justo acabo de publicar una herramienta para administrar chroots sin privilegios para probar ebuilds.
Este cambio hará que Gentoo sea más accesible para mucha gente, pero probablemente no sea para mí.
Mi configuración de compilación, por ejemplo CFLAGS, seguramente nunca coincidirá con los binarios oficiales, así que al final no la usaré.
Cuando usaba Gentoo en entornos de producción, quitar funciones e integraciones con software que no usábamos se volvió una parte importante de nuestra postura de seguridad.
Eso sí, siempre tuvimos un host de compilación dedicado para generar binarios, pero el soporte de Gentoo para binarios no era muy bueno.
Básicamente se limitaba a servir los artefactos compilados por HTTP o NFS, sin firma.
Me entusiasma mucho que el nuevo formato de paquetes incluya verificación criptográfica.
Aunque sea para distribución interna, es una función que debería haber existido desde el principio.
Es útil cuando no quieres configurar un binrepo aparte, especialmente si entra en juego la compilación cruzada, pero aun así quieres reutilizar tu configuración existente de Portage y ebuilds personalizados.
ChromeOS usa bazel para ejecutar ebuilds dentro de un chroot temporal.
https://chromium.googlesource.com/chromiumos/bazel/+/refs/he...
Así se puede garantizar que no se usen dependencias no declaradas.
Aun así, me tienta hacer un script que sobreescriba los paquetes relacionados con plasma para usar binarios comunes.
Si compilo yo mismo las cosas donde la velocidad importa y recibo como binarios los paquetes de GUI, probablemente pueda ahorrar muchísimo tiempo de compilación.
No creo que la pérdida sea muy grande.
Estuve buscando desesperadamente algo así para mi proyecto de sandboxing.
Digan lo que digan sobre el concepto de Gentoo, a los 17 años fue realmente divertido aprender sobre empaquetado de software, compilación distribuida, los detalles de la optimización en tiempo de compilación y la optimización del kernel de Linux
Según recuerdo, la documentación de la comunidad también era bastante buena
Quizá algunos de los parches que envié todavía estén por ahí en alguna parte de algunos lanzamientos
Pero recién después de ver que una máquina con Slackware corría tan rápido como una con Gentoo, me di cuenta de que todos esos ajustes y optimizaciones, y el software más reciente, no valían tanto la pena
En apps específicas, por ejemplo en una granja de renderizado o en un minero de criptomonedas, la compilación personalizada y los ajustes pueden ayudar, pero en los juegos obtenía los mismos FPS en cualquier distribución
Antes, si compilabas para el mínimo común denominador, ni siquiera incluías MMX o SSE, y en algunos algoritmos ligados a la CPU eso podía marcar una gran diferencia
Pero siempre fue posible detectar en runtime las capacidades de la CPU y ejecutar la versión óptima, así que elegir funciones en tiempo de compilación no era la única forma
Luego llegó AMD Opteron y todos subieron a una nueva línea base
Compilar para amd64 volvió a significar una CPU específica, y en ese momento todavía no había instrucciones más nuevas
Ahora AMD64 tiene varios niveles[1], lo que puede importar en ciertas tareas como SIMD
Como ejemplo más común que aparece con frecuencia, popcnt, agregado en v2, por sí solo es bueno para cosas como bitsets, pero en mis proyectos casi no pude medir diferencias entre v1 y v3 en el rendimiento del programa completo
En el caso de los juegos, probablemente eran solo binarios y ya estaban compilados para el mínimo común denominador, o usaban selección de funciones en runtime
Además, la mayoría seguramente estaba limitada por el cuello de botella de la GPU de todos modos
[1] https://en.wikipedia.org/wiki/X86-64#Microarchitecture_level...
Hace unos años, por alguna razón que ya ni entiendo, desperdicié horas y días de tiempo de computadora y de mi propio tiempo compilando y ajustando al detalle un sistema Gentoo
Y eso que al día siguiente pensaba formatearlo para instalar el CD de Ubuntu recién llegado
Quienes alguna vez compilaron su propio kernel y ahora ya no lo hacen son, al menos en parte, las personas capaces que son hoy porque lo intentaron aunque fuera por un tiempo
Después de haberlo hecho, recién ahí es razonable decidir no hacerlo más
No está bien decir “si hubiera sido más inteligente, no habría perdido tiempo en eso”, ni que alguien nuevo lo interprete así
Al final me cansé y me pasé a Arch, y obtuve casi lo mismo sin tener que pelearme todo el tiempo con paquetes rotos
Aun así, sigo usando hasta hoy el conocimiento que gané lidiando con problemas de bajo nivel aleatorios
Aun así aprendí mucho
Hoy Linux se siente como mi superpoder
El SO, las VM, los contenedores, Nix-shell y WSL2 son todos Linux
Caiga en la línea de comandos que caiga, y hasta cierto punto también en BSD, me siento cómodo y puedo resolver problemas
Me gusta pensar que los buenos momentos que pasé con Gentoo me llevaron a eso
En CentOS, incluso para usar un reproductor de línea de comandos como mpg123, te exigía instalar todo X, pero en Gentoo podías desactivar la integración con X de mpg123
Las flags eran un extra encima de eso
Ahora instalo Debian, agrego solo algunos programas que uso a diario y listo
Puedo recrear mi configuración en otra máquina en menos de 20 minutos
Usé Gentoo durante mucho tiempo a principios de los 2000, y casi todo lo que sé sobre máquinas Linux en general lo aprendí de esa experiencia
Lo interesante de las flags USE era que te enterabas de que cierto paquete tenía integraciones específicas con otras bibliotecas o paquetes
Al darme cuenta de que el binario de SQLite3 no se comporta igual si se enlaza sin soporte de readline, empecé a entender qué era readline en general
Eso se repitió con muchísimas bibliotecas que en otros sistemas Linux parecen estar siempre incluidas de forma invisible
Fue una herramienta de aprendizaje valiosísima que llegó en el momento adecuado de mi vida
Se siente un poco raro
Muchos comentarios dicen que probaron Gentoo o que lo usaban antes
Pero yo todavía lo uso como máquina principal diaria y como base principal en servidores
Me da curiosidad qué es distinto para que Gentoo sea lo mejor para mí
Y no pienso activar los paquetes binarios
Corro Gentoo en todos mis dispositivos: GPD Win 4, Pixelbook con coreboot, NAS, VPS, etc.
Creo que las razones son estas
Si quieres SystemD, úsalo; si quieres OpenRC, lo usas directamente
En Gentoo me siento seguro y cómodo
Porque sé que Gentoo siempre respetará la libertad, lo que más valoro en Linux
Gentoo es como un libro de aventuras de “elige tu propia aventura”
Si quieres usar SystemD + Gnome + PulseAudio + paquetes binarios, puedes; y si quieres usar OpenRC + Hyprland + Pipewire + NetworkManager en vez de netifrc, también puedes
Gentoo no es una distribución en la que compilas todo, sino una distribución en la que eliges todo
Este anuncio no me afecta, pero les da más opciones a los usuarios
Gentoo también es bueno, pero vivir como administrador de sistemas NixOS es mucho más fácil que vivir como administrador de sistemas Gentoo
No lo pregunto para rebatirte si respondes, de verdad tengo curiosidad
En mi caso, la razón por la que Gentoo no me encajó es que no administro servidores personales y en el trabajo uso servidores en la nube
Probablemente basados en Ubuntu o al estilo AWS, pero no compilo kernels ni nada parecido
En el escritorio, hace más de 10 años un amigo me convenció de probar Gentoo diciendo que “como se compila para tu hardware, será más rápido”
Perdí mucho tiempo instalándolo y haciéndolo funcionar, pero en ninguna de las tareas que hago fue notablemente más rápido que un Ubuntu común, y solo me tomó más tiempo configurarlo
Así que lo dejé
También eso de “aprendí muchísimo configurando Gentoo”, que se oye con frecuencia, en mi caso fue falso
Como la mayoría, seguí recetas, configuré flags que no entendía y toqué archivos de configuración; siendo prudente, no aprendí nada
Solo seguí un procedimiento
Claro, esa fue mi experiencia
No lo sé con precisión, pero yo también lo uso desde hace 20 años
Me refiero no a una máquina principal diaria o un servidor que tocas cada semana, sino a equipos que configuraste hace mucho y que desde entonces han seguido funcionando
Hablo de sistemas en los que inicias sesión solo unas pocas veces al año
Dejé Gentoo cuando monté mi primer sistema “en producción”
La gente empezó a usarlo y quedó “terminado” en el sentido de que ya no había motivo para iniciar sesión a diario o cada semana
Seguía queriendo actualizaciones de seguridad, y muy de vez en cuando necesitaba algún paquete nuevo por una función nueva, pero básicamente quería un sistema estable
Gentoo encajaba pésimamente con ese uso
Incluso en mi escritorio personal actualizaba cada semana y casi siempre había algún fallo de compilación con emerge; un sistema que puede pasar meses sin actualizarse sería peor
Por eso me fui a Debian y me fue bien
Me gustaron especialmente las unattended upgrades, y al final migré todas mis máquinas a Debian
Si usas Gentoo, me da curiosidad si también tienes máquinas que no tocas cada semana, con qué frecuencia las actualizas y con qué frecuencia hace falta intervención manual para completar las actualizaciones
Es muy poco y llegó 15 años tarde
Una de las razones por las que me pasé de Gentoo a FreeBSD hace más de 15 años fue que en Gentoo había que compilar todo, mientras que FreeBSD ofrecía paquetes binarios
Hoy quizá no sea tan importante, pero en la época de un solo núcleo de CPU y 1 GB de RAM, eso cambiaba las reglas del juego
Usé Gentoo durante mucho tiempo, luego me pasé a macOS por unos años, y en ese período usé Gentoo prefix, que era muy superior a Homebrew
Hace casi 10 años agregué un parche para que el llvm upstream funcionara en Gentoo prefix sobre macOS [1]
En un evento de reunión de GSoC finalmente conocí a alguien que quería darme permisos de mantenedor, pero eso nunca llegó a concretarse
Él ya me había advertido que ese trabajo sería complicado
Yo seguía diciendo que prefix también necesitaba binarios
Me quedo imaginando cómo habría sido si Gentoo prefix en Mac hubiera podido instalar paquetes tan fácilmente como Homebrew
Es triste, pero Gentoo es un buen ejemplo de que incluso un proyecto open source técnicamente superior no puede sobrevivir imponiéndose a soluciones inferiores si ignora la comodidad básica del usuario final y no tiene una buena estructura de mantenimiento
Creo que opensolaris/illumos terminó básicamente dependiendo de soporte vital por razones parecidas
Sus responsables no lograron superar el elitismo y no pudieron decidir que, para la participación de la comunidad, hacía falta algo más simple que 100 capas de espagueti incomprensible de makefile/shell para compilar el kernel
[1] https://github.com/fishman/timebomb-gentoo-osx-overlay/tree/...
Gentoo siempre fue un nicho incluso dentro de la comunidad Linux, que ya es de nicho, pero aun así parece seguir avanzando con alegría
¿Cuál es el problema?
Me da escalofríos pensar cuántos costos de electricidad y gases de efecto invernadero se habrán generado compilando innecesariamente el mismo software una y otra vez.
Gentoo tampoco fue tan usado en comparación con Red Hat o Ubuntu.
Además, si la computadora de todos modos ya estaba encendida, el consumo de energía de la CPU es un error de redondeo comparado con cosas como un HDD giratorio o un monitor.
Algunas personas juegan 12 horas al día en PCs gamer de kilovatios, manejan autos en pistas o pasean en botes que consumen muchísimo combustible.
Lo que hace excelente a Gentoo es que fue diseñado desde el principio para que sea fácil agregar y mantener ese pequeño ajuste que quiero en mi sistema.
Todas las demás distribuciones que he usado, todas las principales y varias pequeñas, tienden a funcionar mejor en su estado predeterminado, pero si te sales del camino marcado, viene muchísimo sufrimiento.
Un sistema Gentoo bien ajustado simplemente funciona™.
No importa qué signifique personalmente “funciona bien” en este contexto.
Puede ser el conflicto de nombres de python 2to3 que aparece cuando Arch decide sobrescribir upstream, o un problema de latencia en el núcleo del sistema porque SystemD hace demasiadas cosas innecesarias en modo kernel.
A pesar de sus varios defectos, soy un usuario de Gentoo muy satisfecho.
Los paquetes binarios upstream no son más que otra extensión de esa libertad.
Ya existían versiones binarias de algunos proyectos importantes, o podías crear tu propio servidor de compilación, pero si se vuelve fácil usar más binarios, mucha más gente podrá aprovechar esos beneficios sin la enorme carga de tiempo que implica compilar cada pequeña cosa.
Si para algún paquete específico necesitas más flexibilidad, por ejemplo parches o flags use, sigue siendo posible y fácil de mantener.
Esto es una gran victoria.
Durante un tiempo hubo un momento adecuado en el que Gentoo realmente funcionaba con mucha fluidez.
No había ni demasiadas ni muy pocas useflags, y eran los tiempos de recompilar Open Office cuando el cuarto del dormitorio estaba demasiado frío en una noche de invierno.
Lo digo con cariño.