openSUSE ALP parece ser el futuro que tome openSUSE, al menos en algunos de sus «sabores» actuales. Richard Brown en la lista de correo de la comunidad quiere aclarar algunos conceptos
En el blog he escrito algunos artículos sobre las novedades de ALP (Adaptable Linux Platform), el futuro en el que se están enfocando SUSE como desarrollo de nuevas tecnologías basadas en Linux. Para mí en muchos aspectos técnicos es todavía una incógnita sobre la que no sé qué opinar.
La comunidad de openSUSE se verá afectada en la medida en la que openSUSE está basado en el código de SUSE con una gran colaboración de la comunidad a la hora de empaquetar y depurar la distribución.
openSUSE Leap (lanzamientos programados cada año) y openSUSE Tumbleweed («rolling release» o actualización contínua) son sus dos productos más conocidos, ya que son similares a las distribuciones de GNU/Linux actuales.
Pero existen otras alternativas como sistemas inmutables MicroOS ahora en tendencia, por ejemplo. Y en este marco apareció ALP, en mi caso con muchas interrogantes que todavía no sé bien cómo resolver.
Para dar luz a esas dudas y responder a la comunidad, Richard Brown, que fuera presidente del openSUSE Board y colaborador de openSUSE desde hace muchos años, ha enviado un correo a la lista de correo de la comunidad en el que informa a la comunidad de openSUSE de qué supone ALP para la comunidad y empezar a discutir sobre ello.
Os traduzco el contenido del correo para dar a conocer lo que será ALP y sus implicaciones en openSUSE, espero que os sea de utilidad y responda muchas cuestiones.
Estas son las palabras de Richard Brown en el correo que envió (es una traducción/adaptación, si en algo tienes dudas consulta el correo original):
Quería escribir este correo para que todos supieran el estado actual de los esfuerzos de ALP (Plataforma Linux adaptable) de SUSE y, con suerte, poner el tema encima de la mesa con la comunidad de openSUSE haciendo uso de sus esfuerzos.
Este es un correo largo, pero he hecho todo lo posible para ser breve y cambiar los detalles técnicos más esotéricos y añadirlos como apéndice para los más interesados en contribuir.
Primero, quiero aclarar «¿Qué es SUSE ALP?»
SUSE ALP no es un solo un producto nuevo de SUSE, del mismo modo que SLE (SUSE Linux Enterprise)
no es un solo producto. Al igual que ahora, donde SUSE tiene SLES (SUSE Linux Enterprise Server), SLED (SUSE Linux Enterprise Desktop), SLE Micro, SLE para SAP y más, SUSE ALP es una ‘plataforma’ que va a producir familias enteras de productos.
Sin embargo, la diferencia clave que define entre SLE y ALP es que SUSE está creando ALP con «Adaptabilidad» como un aspecto central absoluto. Esto debería reducir o eliminar la situación que a menudo vemos con SLE, donde los productos están ‘atascados’ utilizando las mismas versiones de los componentes principales como glibc y python durante toda la vida útil de un código base.
Con ALP, SUSE creará cosas de una forma en la que diferentes productos ALP pueden tener diferentes versiones de componentes principales, ser compatibles por diferentes periodos de tiempo, y con versiones antiguas de aquellos componentes se retiren cuando ya no se necesiten.
Esta es también la razón por la que no escuchas la frase sobre una ‘base de código’ ALP singular,
porque la forma en que se construyen los productos ALP podrían aprovechar potencialmente múltiples bases de código, potencialmente con ciclos de vida muy diferentes; p.ej. Un producto ALP puede ser lo que la mayoría llamaría una distribución muy «estable», otro podría ser ‘rolling’, y un tercero podría ser un híbrido entre los dos.
Siento que esto es lo más emocionante de ALP, y es el aspecto más interesante de ingeniería de ALP, ya que cambia drásticamente CÓMO construir estos productos en OBS. Mira el apéndice para los detalles.
Entonces, si ALP no es un solo producto, ¿qué está construyendo SUSE?
Los esfuerzos actuales de SUSE se centran en dos productos SUSE ALP, que actualmente se pueden ver en OBS como SUSE:ALP:Products:Bedrock y :Micro. Es poco probable que estos nombres sean definitivos, pero se espera que sean productos centrados en el servidor, que se apoyan en gran medida en actualizaciones transaccionales y contenerización para impulsar aún más los objetivos centrales de «Adaptabilidad» de ALP.
Es mucho más fácil cambiar e intercambiar qué versiones de bibliotecas hay en juego cuando (casi) todo lo que los usa está en contenedores y el sistema operativo está para ser pensado como una unidad cohesiva que se actualiza en operaciones atómicas. Estos no serán los dos únicos productos que SUSE crea a partir de ALP, pero es un punto de partida.
En el futuro, al igual que para la familia de productos SLE, el principal entorno de creación de estos productos tendrá que ser el servicio de construcción interna de SUSE (N.d.T: Un OBS propio donde se crean los productos de SUSE). Esto es para que SUSE pueda certificar estas ofertas comerciales de ALP de la forma en que se requiere que lo sean.
Sin embargo, queremos que ALP, tanto el código como la forma diferente de construir las cosas, estén disponibles para openSUSE e idealmente reutilizados/adaptados para las propias ofertas de openSUSE. Todavía queremos construir ALP en open además de lo que necesitamos hacer para las ofertas comerciales de SUSE.
Por lo tanto, el plan de trabajo actual es el siguiente:
- Todos los productos SUSE ALP se compilarán en el Servicio de compilación interno de SUSE, utilizando fuentes que se originaron en openSUSE:Factory
- Todos los paquetes utilizados para crear productos SUSE ALP se copiarán en Open Build Service de openSUSE sin alteración.
- Todos los productos SUSE ALP se copiarán del IBS (Internal Build Service) de SUSE al OBS (Open Build Service) de openSUSE y las únicas modificaciones serán el cambio de marca obviamente necesario.
- Cualquier cambio futuro en el flujo de trabajo de desarrollo de ALP de SUSE (p. ej., la posible introducción futura de un flujo de trabajo basado en git para enviar cambios a IBS/OBS) también se introduciría para cualquier producto de ALP de openSUSE.
Todo esto debería sonar muy familiar porque es muy similar en concepto a lo que ya hacemos con Leap Micro
Me gustaría hacer la siguiente sugerencia a openSUSE sobre los próximos pasos que podría tomar para extender lo anterior.
Cualquier nueva distribución de openSUSE, como las discutidas como https://en.opensuse.org/Portal:16.0 o https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll, debe construirse como «Productos» separados usando la nueva forma ALP de construir cosas.
El concepto ALP debe ser lo suficientemente flexible como para que estos productos openSUSE puedan aprovechar todo lo que SUSE está haciendo para los productos ALP de SUSE, pero luego nosotros (la comunidad de openSUSE) podemos agregar lo que queramos. Si encontramos que no es lo suficientemente flexible, entonces nosotros (SUSE) trabajaremos para adaptarlo para que la comunidad pueda construir lo que quiere.
Entonces, si nosotros, la comunidad, queremos construir algo como el viejo Leap, eso debería ser técnicamente factible. Ciertamente puedo imaginar a la comunidad construyendo algo con una cadencia de lanzamiento estable y que no use actualizaciones transaccionales y contenedores para ejecutar todo. Si esa es la dirección que queremos tomar como comunidad, deberíamos poder comenzar pronto cuando lo anterior esté en su lugar disponible en OBS.
El mayor desafío que preveo sería garantizar que tengamos suficiente gente para mantener todos los paquetes en esa forma ‘anticuada’ de hacer las cosas, especialmente con SUSE yendo en una dirección diferente… pero ese siempre ha sido un aspecto de la forma de openSUSE de hacer las cosas.
También podría ver un futuro en el que aprovechemos esta oportunidad para probar algo como una versión basada en ALP en MicroOS Desktop, más pulida, obstinada y menos «amigable con los retoques» que el viejo Leap. Me imagino que ciertamente sería posible; también, tal vez en paralelo, si la gente quiere construirlo.
Este enfoque también encajaría muy bien con todo el increíble trabajo que ha estado haciendo el equipo de Agama (anteriormente conocido como ‘D-Installer’), ya que deberíamos poder ofrecer una única instalación ISO que ofrezca todas las ofertas combinadas de «openSUSE ALP», incluidas las copias idénticas de openSUSE de los Productos de SUSE, así como cualquier otra creada exclusivamente por openSUSE.
Potencialmente, esto eliminaría mucho del trabajo necesario para los productos solo de openSUSE ya que (hablando por experiencia), crear y mantener los medios de instalación suele ser el mayor problema.
¿Qué piensan todos?
No reproduzco el apéndice con detalles más técnicos, si te interesan, te remito a que lo consultes en el correo original.
Hasta aquí las explicaciones de Richard Brown en la lista de correo, ahora esperemos que la comunidad plantee sus dudas y sugerencias y veamos por dónde se dirigen los caminos.
No sé si resuelve dudas o plantea nuevas preguntas que todavía no ha sabido responder a la luz de lo comentado.
Como complemento a esto, os enlazo a un hilo en Reddit donde también se está discutiendo esto mismo y planteando cosas.
Por mi parte, de momento no me decanto, estoy a la expectativa de ver cómo evoluciona el tema, qué se va diciendo y qué conclusiones se van sacando. Si quieres compartir tu opinión, usa los comentarios, para complementar la información y para poner en común tus ideas al respecto.
Victorhck in the free world 