Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Lanzamientos y actualizaciones estables del kernel

El modelo de lanzamiento estable del kernel de Linux comenzó en 2005, cuando se determinó que el modelo de desarrollo del kernel existente (una nueva versión cada 2-3 meses) no satisfacía las necesidades de la mayoría de los usuarios. Los usuarios querían que se corrigieran errores durante esos 2-3 meses, y las distribuciones de Linux encontraron difícil mantener los núcleos actualizados sin los comentarios de la comunidad del núcleo. En general, los intentos de mantener seguros los núcleos individuales y con las últimas correcciones de errores fueron un esfuerzo grande y confuso por parte de muchas personas diferentes.

Las versiones estables del kernel se basan directamente en las versiones de Linus Torvalds y se publican aproximadamente cada semana, dependiendo de varios factores externos (época del año, parches disponibles, carga de trabajo del mantenedor, etc.). La numeración de las versiones estables comienza con el número de la versión del kernel y se agrega un número adicional al final. Por ejemplo, Linus publica el kernel 4.4, y luego las versiones del kernel estable basadas en este kernel se numeran 4.4.1, 4.4.2, 4.4.3, etc. Esta secuencia generalmente se abrevia con el número 4.4.y cuando se hace referencia a un árbol de lanzamiento de kernel estable. Cada árbol de lanzamiento de kernel estable es mantenido por un único desarrollador de kernel, quien es responsable de elegir los parches necesarios para el lanzamiento y administrar el proceso de revisión / lanzamiento.

Los núcleos estables se mantienen durante todo el ciclo de desarrollo actual. Después de que Linus lanza un nuevo kernel, el árbol de lanzamiento del kernel estable anterior se detiene y los usuarios deben pasar al kernel más reciente.

Núcleos estables a largo plazo

Después de un año de este nuevo proceso de lanzamiento estable, se determinó que muchos usuarios diferentes de Linux querían que un kernel fuera compatible por más de unos pocos meses. En respuesta, se creó la versión del kernel Long Term Supported (LTS), con el primer kernel LTS (2.6.16) lanzado en 2006. Desde entonces, se ha seleccionado un nuevo kernel LTS una vez al año y la comunidad del kernel mantiene ese kernel durante un mínimo de 2 años.

En el momento de escribir este artículo, los kernels LTS son las versiones 4.4.y, 4.9.y, 4.14.y, 4.19.y, 5.4.y y 5.10.y. Se lanza un nuevo kernel semanalmente. Debido a las necesidades de algunos usuarios y distribuciones, los desarrolladores del kernel mantienen algunos núcleos antiguos adicionales en un ciclo de lanzamiento más lento. Información sobre todos los núcleos estables a largo plazo, que está a cargo de ellos, y cuánto tiempo se mantendrán, se puede encontrar en la kernel.org los estrenos de la página.

Los lanzamientos del kernel LTS tienen un promedio de 6-8 parches aceptados por día, mientras que los lanzamientos normales del kernel estable contienen de 10 a 15 parches por día. El número de parches fluctúa por lanzamiento dado el tiempo actual del lanzamiento del kernel de desarrollo correspondiente y otras variables externas. Cuanto más antiguo es un kernel LTS, menos parches se le aplican, ya que muchas correcciones de errores recientes no son relevantes para los kernels más antiguos. Sin embargo, cuanto más antiguo es un kernel, más difícil es respaldar los cambios que se deben aplicar, debido a los cambios en la base de código. Entonces, si bien puede haber un menor número de parches en general que se están aplicando, el esfuerzo involucrado en mantener un kernel LTS es mayor que mantener el kernel estable normal.

Reglas de parches de kernel estables

Las reglas para lo que se puede agregar a una versión estable del kernel se han mantenido casi idénticas desde su introducción y se resumen a continuación:

  • Obviamente debe ser correcto y probado.
  • No debe tener más de 100 líneas.
  • Debe arreglar solo una cosa.
  • Debe solucionar algo que se ha informado que es un problema.
  • Puede ser una nueva identificación de dispositivo o una peculiaridad del hardware, pero no agregar una nueva funcionalidad importante.
  • Ya debe estar fusionado con el árbol de Linus Torvalds.

La última regla, "Ya debe estar fusionado en el árbol de Linus Torvalds", evita que la comunidad del kernel pierda arreglos. La comunidad nunca quiere que una solución entre en una versión estable del kernel que no esté ya en el árbol de Linus Torvalds, por lo que cualquiera que actualice nunca debería ver una regresión. Esto evita muchos problemas que pueden tener otros proyectos que mantienen una rama estable y en desarrollo.

Actualizaciones del kernel

La comunidad del kernel de Linux ha prometido a su base de usuarios que ninguna actualización romperá nada que esté funcionando actualmente en una versión anterior. Esa promesa sigue siendo válida hoy. Las regresiones ocurren, pero esos son los errores de mayor prioridad y se corrigen rápidamente, o el cambio que causó la regresión se revierte rápidamente desde el árbol del kernel de Linux.

Esta promesa es válida tanto para las actualizaciones incrementales del kernel estable como para las actualizaciones importantes más grandes que ocurren cada tres meses. Sin embargo, la comunidad del kernel solo puede hacer esta promesa para el código que se fusiona en el árbol del kernel de Linux. Cualquier código que se fusionó en el núcleo de un dispositivo que no está en los kernel.org comunicados es desconocida y las interacciones con los que nunca se puedan programar, o incluso considerado.

Los dispositivos basados ​​en Linux que tienen grandes conjuntos de parches pueden tener problemas importantes cuando se actualizan a kernels más nuevos, debido a la gran cantidad de cambios entre cada versión (10-14 mil cambios por versión). Los conjuntos de parches de SoC son especialmente conocidos por tener problemas con la actualización a kernels más nuevos debido a su gran tamaño y a la gran modificación del código del kernel específico de la arquitectura y, a veces, del núcleo. Como resultado, la mayoría de los proveedores de SoC están comenzando a estandarizar el uso de las versiones LTS para sus dispositivos, lo que les permite recibir actualizaciones de errores y seguridad directamente desde la comunidad del kernel de Linux.

Seguridad

Al hacer versiones del núcleo, el núcleo de Linux comunidad casi nunca se declara cambios específicos como los parches de seguridad. Esto se debe al problema básico de la dificultad para determinar si una corrección de errores es una corrección de seguridad o no en el momento de la creación. Además, se determina que muchas correcciones de errores solo están relacionadas con la seguridad después de que haya pasado mucho tiempo, por lo que la comunidad del kernel recomienda encarecidamente que siempre se realicen todas las correcciones de errores que se publican.

Cuando los problemas de seguridad se informan a la comunidad del kernel, se solucionan lo antes posible y se envían públicamente al árbol de desarrollo y las versiones estables. Como se describió anteriormente, los cambios casi nunca se describen como una "solución de seguridad", sino que se parecen a cualquier otra corrección de errores del kernel. Esto se hace para permitir que las partes afectadas actualicen sus sistemas antes de que el informante del problema lo anuncie.

Para obtener más detalles sobre cómo informar errores de seguridad a la comunidad del kernel para conseguir que resolver y se fijan tan pronto como sea posible, se refieren a errores de seguridad en la guía del usuario del núcleo de Linux y administrador de al www.kernel.org .

Debido a que el equipo del kernel no anuncia al público los errores de seguridad, los números CVE para los problemas relacionados con el kernel de Linux generalmente se publican semanas, meses y, a veces, años después de que la solución se fusionó con las ramas estable y de desarrollo.

Mantener un sistema seguro

Al implementar un dispositivo que usa Linux, se recomienda enfáticamente que todas las actualizaciones del kernel LTS sean tomadas por el fabricante y enviadas a sus usuarios después de que las pruebas adecuadas muestren que la actualización funciona bien. Esto tiene varias ventajas:

  • Los desarrolladores del kernel han revisado las versiones en su conjunto, no en partes individuales.
  • Es difícil, si no imposible, determinar qué parches solucionan problemas de "seguridad" y cuáles no. Casi todas las versiones de LTS contienen al menos una solución de seguridad conocida y muchas aún "desconocidas".
  • Si las pruebas muestran un problema, la comunidad de desarrolladores del kernel reaccionará rápidamente para resolver el problema.
  • Los intentos de filtrar solo los cambios que ejecute darán como resultado un árbol del kernel que es imposible de fusionar correctamente con futuras versiones anteriores.