El desarrollo de versiones LTS de Linux podría acortarse por temas con el mantenimiento
Hace pocos días en el sitio web de «Linux Journal» se compartió una publicación en la cual hablan un poco sobre los temas tratados en la Open Source Summit Europe, en la cual Jonathan Corbet, desarrollador del kernel de Linux menciono un poco sobre el rumbo que estaría tomando el desarrollo dentro del Kernel de Linux en los próximos años.
En la publicación se resalto con gran importancia el tema del desarrollo de las versiones LTS de Linux, las cuales en estos momentos y a futuro podrían ser un gran problema, dadas las características de estas versiones, siendo en especial el tema del tiempo de soporte que tienen estos.
Y es que en la publicación se menciona que los desarrolladores del kernel de Linux, pretenden limitarse a un ciclo de actualización de dos años para las ramas LTS del kernel de Linux. Formalmente, el tiempo de mantenimiento para las versiones de LTS sigue siendo de 2 años, pero durante los últimos cinco años el período de lanzamiento de actualizaciones se ha extendido a 6 años si el kernel continúa teniendo demanda y los representantes de la industria están listos para ayudar a los desarrolladores a brindar mantenimiento.
En el futuro, dicha extensión se cuestiona, ya que hay una disminución en el interés en el uso de kernels LTS antiguos: la mayoría de los usuarios transfieren sus productos a ramas de kernel más nuevas con anticipación y 6 años se percibe como un período excesivo.
Además, a medida que aumenta el número de versiones LTS, aumenta la carga sobre los mantenedores, cuyo trabajo se vuelve rutinario y se reduce a un soporte continuo de correcciones. Esta carga provoca agotamiento de los asistentes y pérdida de interés en continuar trabajando.
El agotamiento del mantenedor se considera uno de los problemas más graves en la comunidad de desarrollo del kernel. A pesar del apoyo de las corporaciones, la mayoría de los participantes en el desarrollo del kernel actúan como voluntarios por interés: sólo unos 200 desarrolladores de más de 2.000 participantes activos en el desarrollo reciben un pago por su trabajo. La constante monotonía de corregir errores menores, realizar pruebas difusas y revisar cambios agota a los desarrolladores y conduce a una pérdida de interés en el trabajo del mantenedor.
Este agotamiento del mantenedor representa una seria amenaza, como destacó Corbet. El mantenimiento de Linux es en gran medida un esfuerzo voluntario, y sólo unos 200 de los más de 2000 desarrolladores pagaron por sus contribuciones. Las interminables exigencias de tiempo de los mantenedores debido a las pruebas de fuzz, la corrección de errores menores y la revisión de las contribuciones pasan factura. Destacados mantenedores han advertido que necesitan ayuda para evitar el colapso. Las empresas que dependen de Linux deben darse cuenta de que retribuir financieramente les conviene para sostener este ecosistema vital.
Entre los problemas también se destaca el peligro de la aparición de ramas del kernel de Linux que se separan del kernel principal y dependen de proveedores individuales. Ramas como esta pueden resultar de distribuciones como Red Hat Enterprise Linux que utilizan paquetes de kernel basados en versiones muy antiguas del kernel con cambios respaldados.
El peligro de estas ramas es que, al transferir cambios de forma selectiva, es posible que se pierdan correcciones para vulnerabilidades y problemas graves. Además, dificultan el análisis de los errores que se producen, ya que no siempre queda claro si el problema se manifiesta en el núcleo principal o es causado por cambios específicos del fabricante.
Se menciona que un modelo más correcto para mantener kernels, es seguir un modelo similar al de Android que se basa en transferir todos los cambios del kernel principal y desarrollar las innovaciones necesarias en el kernel principal, en lugar de mantener su propia versión del kernel, incluidos los cambios específicos de la plataforma Android.
El modelo de migración de cambios completos es beneficioso principalmente desde el punto de vista de la seguridad, ya que cuando los parches se migran selectivamente, la conexión entre la solución y la eliminación de posibles problemas de seguridad no siempre es obvia. Cuando los cambios se migran por completo, el problema a menudo se resuelve antes de que haya información de que la solución bloquea la vulnerabilidad.
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.